Why I Choose HTML 4.01

Note: this post from 2009 is a bit old now, and was written in the days where XHTML was being promoted in favor of HTML4. Of course, nowadays HTML5 has taken over from both.

Any page authored for the web should begin with a DOCTYPE declaration. The reasons for this are essentially twofold:

a DOCTYPE allows you to tell tell a page validator what standard to measure your code against
browsers will understand that your code follows web standards and will render the page accordingly.

The real question is which DOCTYPE to use, as there are many available. For normal purposes, there are really two main ones to choose from: HTML 4.01 Strict and XHTML 1.0 Strict. Here is the code for each:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

There are versions other than Strict, such as Transitional; but if you are serious about good design you will use a Strict DOCTYPE. Period.

Since the early 2000s there has been a strong push to adopt XHTML over HTML. There are many reasons given, and some of the arguments are compelling. (“XHTML is the future of the web”… “There will be no versions of HTML beyond HTML 4.01”… and so on.) But to be honest, I’ve never been all that convinced, and recently I decided to abandon XHTML in favor of HTML. Here’s why …

XHTML Does not work in Internet Explorer

Many people are shocked to hear this. “But I’ve been using XHTML for years, and never had any problem with it in IE.” Well, if you believe that, you’ve been misled. The only reason XHTML appears to work in IE is that it is served up as Text/HTML:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

In other words, you are telling browsers to read your code as HTML, not XHTML. The proper way to serve up XHTML is with the application/xhtml+xml MIME type, but IE will choke on that. There are workarounds for this, but they are incredibly convoluted and require significant back-end coding skills (see links below).

And for me, it begs the question, Why bother? What is to be gained? XHTML apparently is a kind of transitional step from HTML to XML, with a view to XML one day replacing HTML. Perhaps that would be a great day, but it’s a long, long way off. XHTML may be more useful if you are creating an XML-based web application of some kind, but that sounds like a pretty rare situation—certainly not something that I ever do.

Some will argue that using XHTML now will prepare you for the future, but there are two points against this. Firstly, it appears that XHTML 2.0 will not be backward compatible—meaning that when it comes along, you will have to re-write your code anyway (in which case you might as well stay with HTML for now). Secondly, unless you are testing your XHTML with the application/xhtml+xml MIME type, it is likely that there are many errors in your XHTML code anyway (which XHTML served as Text/HTML will let you get away with, but which the much stricter XML rules will not allow). Apparently, this is especially so in relation to the handling of JavaScript, as pointed out at SitePoint. These errors will come back to haunt you eventually, and your site will be no better off than if it was written in HTML. When, if ever, you end up switching MIME types, you’ll have to make a lot of changes anyway.

XHTML served as Text/HTML only works because of a Hack

Unfortunately, XHTML served as Text/HTML is BAD HTML. It only works in the browser because of browser bugs. In particular, closing empty tags with “ />” (as in <img href=”#” />) is a HACK. It shouldn’t work, but it does, because most browsers have a parser bug that ignores the slash in self-closing tags—as long as you leave the space before them.

XHTML has stricter standards

Yes, that’s true, and it’s an important point. XHTML has stricter validation rules than HTML, and thus it encourages better coding practices. But that doesn’t mean that you can’t apply these best-practices to HTML. Such practices include the use of closing tags, such as </p>. In HTML you can get away with not using a closing tag, whereas you can’t in XHTML. Of course, you can’t in XML either, and hence the urgency to adapt to this usage.

The fact is that you can apply the same best-practices to HTML as to XHTML, and it is quite easy to switch between well-written HTML and XHTML. (Apart from changing the DOCTYPE, you often only need to add in the space+/ at the end of empty elements.)

I could go on, but I’m not an expert in this area, and there is a superb thread at SitePoint on this, which begins with a wonderful comparison of HTML and XHTML by Tommy Olsson (who is an expert).

Acknowledgements & Links

On XHTML v/s HTML: there’s a really good forum thread at SitePoint which you should read to understand this topic better.
SitePoint has a nice overview of the Differences Between HTML and XHTML, including links to other topics such as information about MIME types.
On Doctypes: for a good introduction to DOCTYPES, see this A List Apart article.
On Serving XHTML as application/xhtml+xml, see these sites: 456 Berea Street, Keystone Websites, Hixie (Ian Hickson), Autistic Cuckoo (Tommy Olsson), SitePoint and Perishable Press.