HTML is dead, long live HTML

28 October 2006

The Dead Collector: Bring out yer dead.

Large Man with Dead Body: Here's one.

The Dead Collector: That'll be ninepence.

The Dead Body That Claims It Isn't: I'm not dead.

The Dead Collector: What?

Large Man with Dead Body: Nothing. There's your ninepence.

The Dead Body That Claims It Isn't: I'm not dead.

I'm afraid that I ranted on about XHTML for a while while writing this. You might want to skip to the point.

HTML was dead and XHTML was the future, and that was the end of the matter.

… but Internet Explorer doesn't support XHTML

… but Firefox can't do incremental rendering of XHTML.

… but so many user agents can handle HTML.

So HTML was going to be around for a long time to come. Never fear, Appendix C to the rescue!

And lo! The assembled masses immediately started using XHTML and following the guidelines of Appendix C!

A brief pause while the author has a coughing fit.

XHTML as text/html introduced two problems. The first was that many people treated XHTML as "HTML with some weird '/'s in it" and merrily carried on serving tag soup as text/html, just with an XHTML Doctype and lowercase tag and attribute names (often continuing to camelCase the onClick attribute).

The second was for those people who actually attempted to follow the guidelines in Appendix C (a requirement of serving XHTML as text/html).

  • Appendix C is informative (i.e. its just for information, it doesn't specify anything).
  • Appendix C is vaguely worded: For compatibility with these types of legacy browsers, you may want to avoid using processing instructions and XML declarations.
  • Appendix C is borderline self-contradictory. If C1 means "Don't use processing instructions and always use UTF-8" (which is, in my opinion, the only sensible interpretation), then why does C14 say that you must have a processing instruction for every style element instead of "Do not use style elements"?
  • C14 is all about writing style elements so they work in generic XML. Why is there a guideline for XML compatibility in the "HTML Compatibility Guidelines"?

I could probably go on, but I've filled my editor window with text and I haven't go to the reason for writing this post yet.

So, XHTML, where do we stand? Awful browser support as application/xhtml+xml. A really bad specification for serving it as text/html (where it usually "works"), and serving it as text/html would give you the combined disadvantages of HTML and XHTML along with no actual benefits on the client side (and on the server side its pretty trivial to transform to Appendix C compatible (at least as far as you can follow Appendix C) markup to HTML 4.01.

So for quite a while I've been saying that HTML is the way to go, and quite a few people have been evangelizing XHTML as "the future" (maybe it is, maybe it isn't, but I'd rather my pages worked well today, then worked well if the future you predict does come to pass).

Warning! Warning! Point of this post is coming!

So, this morning I start to catch up on my email and I run across Lachlan Hunt's email asking about the changes to the working groups.

Changes to the working groups? It seems that Sir Tim has noticed that XHTML isn't working out as well (or at least as quickly) as he had hoped, and it was time to do something about it.

I'm not going to get too excited about the changes yes, but it does sound like there is a chance we will see some sensible updates to HTML instead of the Baby/Bathwater approach taken by XHTML 2 drafts, so fingers crossed.

Others have commented already: