Question

I’ve noticed that many web sites are being designed under XHTML Transitional despite adhering to most modern web design practices. I thought transitional was meant as a temporary solution for porting over old markup that may require too much effort to redesign.

And many web sites don’t even validate properly under Transitional. I try very hard to adhere to the strict standards under the belief that improper markup leads to much difficulty debugging when something doesn’t work. However, it is a lot of work writing 100% valid code.

I’m curious as to whether or not it’s worth putting in the effort to learn and write XHTML strict compliant markup.

EDIT: And if it is, why don’t more people do it? It seems rather rare for me to stumble upon a proper XHTML strict web page.

Answer 1

Short answer: no.

I’ve never found Strict XHTML to be worth the effort.

The first problem with it is that it deprecated a number of HTML features which were actually useful, and for which there were no good alternative solutions. This was a particular problem if you needed backward compatibility with older browsers (which of course everyone does). The Transisional spec didn’t deprecate these features, which is why people use it rather than Strict.

Features that were deprecated included the <center> tag (CSS alternatives were not cross-browser compatible at the time) and the target attribute for the <a> tag (which allows you to open a link in a new window, tab or frame; there still isn’t any other way to do this, no-one stopped using it, and HTML5 has re-introduced it). There were quite a few other features along the same lines, but it’s been a long time, and I can’t remember them all.

Secondly, it was designed to cause the browser to fail if your markup had even the smallest error. This sounds great in theory, but was always doomed to failure. It was basically a reactionary step taken by the specification writers against the proliferation of poor-quality HTML code that was (and to some extent still is) a major issue for the web. But they forgot a key rule for designing client-server protocols, which is that the server should be strict about what it sends, but the client should be lenient. All successful client-server protocols follow this rule.

It is good to care about your markup being valid – in fact, it’s very important, regardless of what (x)HTML dialect you’re writing in – but you should be checking that in the development phase, not letting the end user’s browser do your validation for you. If you’re a good developer, you should know that your code is good before it gets anywhere near the user. And in fact, if that causes your site to completely break in front of the end user, then it’s a disaster. With broken HTML, even if it’s quite badly broken, the user can generally navigate and read the site sufficiently to be able to find contact details for you to report the error. With a browser that respects the strict XHTML doctype, a tiny markup error can cause your site to show nothing other than a standard browser error message. This is a very very poor user experience.

Finally, it didn’t provide any new features. The one thing it did which older HTML versions didn’t do was allow the document to be parsed as an XML document. This was good for validating that your document didn’t have any errors, but didn’t really achieve much else. You could also embed other XML formats into your document, using namespaces, but this was complex and didn’t really achieve much new either.

XHTML was always an idealistic dream, and it is thankfully fading away now that HTML5 has taken over as the new-and-exciting-thing.