Re: w3c link checker

Brian <usenet3 (AT) julietremblay (DOT) com.invalid> wrote:

http://validator.w3.org/checklink

Any ideas what I can do to get the link checker to work here?

Could be a bug, it stops working on parts of one of my sites also, you
could try firing off an email to the W3C link checker team.

rant mode="mild"
The W3C had perfectly good services, and decided to change them all. Now
they have nifty new designs that look stupid to me -- are those trees
supposed to mean anything? -- while slowing down the service. On dialup,
those images take time to load. Sometimes, so long that Mozilla Checky
tries to enter the url and submit before it's finished, and the whole
thing fails. I suppose I ought to disable images before using it. (sigh)
/rant

IIRC it's the alternate stylesheets (which are all loaded by UAs) that
makes some of the W3C pages so slow, not the graphics.

On the plus side: this new W3C link checker is the first that I've seen
that claims to check fragment identifiers.

--
Spartanicus

Brian <usenet3 (AT) julietremblay (DOT) com.invalid> wrote:

On the plus side: this new W3C link checker is the first that I've
seen that claims to check fragment identifiers.

I'm fairly certain that old one did, too.

I'm certain it didn't.

I use them for page contents links (see site in sig for examples)

No fragment id's on your index page.

, and if I screwed one up, e.g., by
changing the id of an <h2> element, the link checker told me so. It also
checked fragment id hrefs in <link> elements. Or did I misunderstand you?

Dunno, fragment ids:

<a href="foobar.html#foobar">Foobar</a>

<h2 id="foobar">Foobar</h2>

--
Spartanicus

Brian <usenet3 (AT) julietremblay (DOT) com.invalid> wrote:

this new W3C link checker is the first that
I've seen that claims to check fragment identifiers.

I'm fairly certain that old one did, too.

I'm certain it didn't.

I can't be imagining this! I fixed those links on many occasions after
running the link check.

Odd, I checked specifically for fragment identifier support a few months
ago and concluded that they were not supported. Can't remember how I
arrived at that conclusion tho.

fragment ids:

a href="foobar.html#foobar">Foobar</a

h2 id="foobar">Foobar</h2

It checked fragment ids that pointed to the same page, i.e., on
/site/help it checked if /site/help#search existed. But I don't know if
it checked /site/help#search if that link appeared on another page
entirely, e.g., /menus/.

Perhaps that was it, I looked for cross document support of fragment
identifiers.

--
Spartanicus

Spartanicus wrote:

Brian <usenet3 (AT) julietremblay (DOT) com.invalid> wrote:

this new W3C link checker is the first that
I've seen that claims to check fragment identifiers.

I'm fairly certain that old one did, too.

I'm certain it didn't.

I can't be imagining this! I fixed those links on many occasions after
running the link check.

Odd, I checked specifically for fragment identifier support a few months
ago and concluded that they were not supported. Can't remember how I
arrived at that conclusion tho.

I'm with Brian on this one - it spotted dodgy fragments for me over a
year ago on an XHTML-1.0 Strict site, so they must have been of the
id="" sort rather than name="".

--
Mark.
http://tranchant.plus.com/

Mark Tranchant <mark (AT) tranchant (DOT) plus.com> wrote:

I'm with Brian on this one - it spotted dodgy fragments for me over a
year ago on an XHTML-1.0 Strict site, so they must have been of the
id="" sort rather than name="".

OK, guess I messed up with my test of the old checker earlier. Btw, a
name="#foobar" is also a fragment identifier.

--
Spartanicus