Xhtml Code Validity

5 April, 2007

There was a time when this site was 100% xhtml valid. It didn't last long, as as soon as I forgot to correctly close a tag anywhere on the page, or added some beta-ish new functionality, or updated my cake version inevitably something became invalid. I used the Xhtml Validation helper for a while, but the messages it generated got in the way rather than helping. I still use it for certain tasks, such as checking comments and these blogs for well-formedness, it's a handy class of that there's no doubt but not the way I was trying to use it.

For this site my primary concern is that the code is at least well-formed and preferably 100% valid (xhtml). But rather than trust the W3 Validator to tell me my pages are fine; there's a much faster way to both detect and prompt fixing fundamental errors: Public Embarrassment.

How does it work?

It might be obvious, but the best way to check if something is valid, is to ensure that if it isn't it just plain doesn't work. So with the last update, I switched to serving xhtml where the requesting user agent (browser) can accept it using the following code:

It's a simple test to check that the controller is about to serve html, I'm not debugging (the sql table would break the page), the browser can accept xhtml, and the user has not overriden to say they want html (there's a link at the top right of the page for that). As a consequence anyone using a decent browser (not *cough* Internet Explorer) will get xhtml, while if not you get html. The user override is to ensure that if there is an error (and I'm aware of a number of them at the time of writing that I can't fix immediately) it is possible to see the page so long as at least one other page permits you to display the xhtml and click the link :).

In addition there is a simple test in the layout to check if the user agent is Internet explorer and if so not send the xml declaration, as this also sends Internet explorer into quirks mode.

Benefits of this approach

With a 'normal' browser if your document is xhtml but served as html and it has a wellformedness error in it: you probably don't notice. If you are using internet explorer it would switch to using quirks mode, and that would mean that your carefully crafted hacks-free css file suddenly doesn't quite look like it should ;). However, if you serve it as xhtml to those that can accept it and it has a wellformedness error in it; the big red flag to find and insert that missing </p> tag is waved high and bright for you and everyone else :).

As such, by using xhtml there is a much greater chance of avoiding cross-browser issues,as any modern browser should render the page approximately the same, and any older browser should at least be receiving well formed html (even if it does get treated as soup).

Disadvantages of this approache

If you click the link at the top right of the page to switch between xhtml and html, you may notice at least these 3 things.

• The style of the page changes slightly
• The page isn't displayed until it is fully received
• The adverts disappear
• A simple mistake results in nothing visible

Only the last two of those concern me one for the missing $1 a week I won't be getting from adsense, but I'm sure I can live without it, and the other because, well, it's embarrassing! The cause for the disappearance is that you can't use javascript to modify the DOM before the page is loaded.

Wrapping up

So there you have it, this site is now serving (at least well formed if not valid) xhtml and whenever something is falling short of the mark there'll be an embarrassing parse error message for you to see and me to rectify. Some of the causes for such errors may be tickets for cakePHP but more than likely it will just be a task for me. If you notice an error, especially if it persists for more than a day, please let me know - by adding a comment to this post, contacting me via the contact form or directly on irc - so that I can fix it.

Bake on!