Fossil

View Ticket
Login
Plaintext
2022-07-29
15:51 • Closed ticket [0049db24]: Firefox HTML Validator thinks all pages are full of errors plus 5 other changes ... (artifact: 16cc8878 user: stephan)
2010-03-03
06:16 • Ticket [0049db24]: 2 changes ... (artifact: 32f71baf user: anonymous)
02:15 • New ticket [0049db24]. ... (artifact: 61c462ab user: anonymous)
Ticket Hash: 0049db245ef59671d4fcefd45c02e37a70e2b622
Title: Firefox HTML Validator thinks all pages are full of errors
Status: Closed Type: Feature_Request
Severity: Cosmetic Priority: Zero
Subsystem: Resolution: Overcome_By_Events
Last Modified: 2022-07-29 15:51:52
2.73 years ago 		Created: 2010-03-03 02:15:05
15.14 years ago
Version Found In:
Description:
I habitually install the HTML Validator add-on in Firefox, which provides fast feedback on the currently loaded page. The current version of that add-on (0.8.6.1) believes that every page generated by fossil has numerous errors.

Many of these errors appear to stem from it not recognizing the DOCTYPE, which is likely because the DTD it names is spelled wrong: 

"-//W3C/DTD XHTML 1.0 Strict//EN"

should be 

"-//W3C//DTD XHTML 1.0 Strict//EN"

according to the list of "official" DTD names found at the W3C. (Note the extra slash between W3C and DTD.) As a red herring, the URL mentioned is at the alternate domain x3.org instead of the standard w3.org, but that isn't causing the issue.

With that corrected (at line 94 of style.c) then the number of errors is much lower, but still significant. Typical examples (from the 12 or so listed for the home page of a clone of the fossil-scm.org repository) include:

  • The link tags are all missing end tags.
  • The img tags are all missing end tags.
  • The nobr is not in the standard.
  • There is a table element using the nonstandard hspace attribute.
  • There is one or more extra ul end tags.
  • There is at least one hr tag missing its end tag.
  • There is at least one h3 tag inside the span of a p tag.

Some of these are probably correctable in the .wiki source text for this particular page, but some appear to result from the wiki translation itself.

If the DOCTYPE is going to be XHTML Strict, then it would seem to make sense to clean up the generated HTML so that it passes a validation suite. I've rated this as Cosmetic, although there are probably implications for accessibility applications (screen readers) which could be more serious than that.

anonymous added on 2010-03-03 06:16:12:
I'm not the original poster, I'm just adding some info.

Ticket feb61a11a0f8f911d72347daf334b76766e3a66a (XHTML standard compliance) was related to this ticket.

But this one is more up-to-date and brings more information.