Why I Still Prefer XHTML over HTML

For those of you who enjoying peeking up the skirts of innocent websites, you may have noticed that this site uses XHTML, despite the fact that I get no concrete benefit from using it. Why is that?

Well, let me lay it out for you, and then you can decide if XHTML is worth the extra effort or if HTML is a better choice for you.

XHTML is eXtensible

One very distinct and as yet unused benefit of XHTML is the ability for it to extend itself.  XHTML was designed to grow with the web. In the future extra modules can be added to the XHTML definition to increase its abilities. Sort of like Spiderman’s black suit. Except less evil.

HTML, on the other-hand, has no way to do this. It is set in stone and does not like to play nice with the new kids.

XHTML replicates HTML’s abilities, but also has the ability to extend itself. For example, XHTML2 is planning on integrating a number of modules including a Ruby module, XForms, and XML Events. It can do this relatively easily compared to the old HTML recommendation.

XHTML Protects Me from Myself

Alright, I will admit it, I make mistakes.

When mistakes are made, one should be made aware of them, correct them, and try not to repeat them. That is the essential process to improvement in all aspects of life.

A good parent will tell their child that hitting someone is a mistake, discipline the child, and warn them not to do it again or else. A bad parent will ignore the transgression and continue on as if nothing happened, thus reinforcing negative behavior.

XHTML is a good parent. HTML is a bad parent.

When XHTML is being processed properly (meaning not in Internet Explorer and with the correct MIME type) the browser will immediately stop processing the page when a mistake is found. Hopefully an informative error message will appear so that you can correct the mistake and learn from it.

HTML will find errors, but instead of being a good parent and notifying you of your bad behavior, it simply glosses over it, fixes it behind your back, and presents it as if nothing happened. This is called error-correction and is bad, bad, bad for the web. Like a bad parent, it encourages bad coding technique.

Error-correction is bad, bad, bad for the web.

Ok, so my parents never encouraged any sort of coding technique, but you get what I’m saying.

XHTML is Forward-Compatible

In the future, HTML will die. There is no way around it. Once Internet Explorer jumps on the XHTML wagon, the full benefits of this wondrous new language will finally be put to use.

Many designers argue that you shouldn’t use XHTML, because browsers still encourage bad behavior when it is parsed as HTML, which it invariably is. The argument goes that once all browsers are compatible with XHTML, sites coded with bad XHTML will just choke and fail (like they should) and many people will blame XHTML instead of their own poor coding technique.

A good point, but which do you think will be easier when the time comes?

• Big conversion of old HTML into well-formed XHTML
• Small fixes of poor XHTML into well-formed XHTML

This brings me to my next point.

XHTML is Not Hard

The language itself is pretty similar to HTML. Once you learn the nuances, it is just as easy as HTML. And much more consistent.

So why not use it?