Wandering Thoughts archives


The danger of validating your XHTML

The danger of validating XHTML is that the validation is almost certainly not doing what you believe it's doing.

The problem is that all the common online validators ignore the HTTP Content-Type of what your web server returns when validating your page, and use only the DOCTYPE. This is completely wrong in the case of XHTML, because browsers only treat pages as XHTML if they are served as application/xhtml+xml. All the DOCTYPE does is let the browser decide what sort of XHTML it has, since there are now several flavours.

(No less authority than the W3C says that browsers should behave this way; see this mailing list message, or this Safari blog entry, or even the W3C's XHTML media types note.)

So if you serve your beautifully validated XHTML as text/html, what browsers will actually see it as is good old HTML tag soup. And validators won't tell you this; they will happily tell you that your text/html page is valid XHTML, when an honest answer is that it is invalid HTML.

(In some future world it may be valid HTML5.)

If you are merely using XHTML validation as a good housekeeping seal of approval, you should write to HTML 4.01 Strict instead; it is just as strong, and browsers will actually interpret your pages the way you think they are, saving you various headaches.

If you are using XHTML validation to prepare for serving your pages as application/xhtml+xml in the future, you are probably fooling yourself, because your pages may or may not actually work as real XHTML (see some of the links here for a full explanation).

If you are trying to serve real XHTML to selected browsers and your XHTML document as HTML to Internet Explorer, and you are not using either MathML or SVG, you are a masochist.

web/XHTMLValidation written at 23:28:56; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.