Progress in the W3C

This news should be a boon to you: The W3C HTML WG has finally published first working drafts of the HTML5 - A vocabulary and associated APIs for HTML and XHTML specification and an accompanying HTML 5 differences from HTML 4 document. Here’s your first glimpse at what the successors to XHTML 1 and HTML 4 may look like.

I just want to make something very clear that I apparently failed to make clear in my HTML5, XHTML2, and the Future of the Web article, judging from the comments I got. HTML5 is a specification that does four main things:

• HTML5 defines a vocabulary; being a set of element names, attribute names, allowed attribute values, and allowed content models; and defined semantics for that vocabulary.


• HTML5 defines the DOM which that vocabulary is to parse into.


• HTML5 defines two serialisations for that vocabulary: one XML serialisation that is intended to eventually succeed the XHTML1 specification; and one custom non-SGML HTML serialisation, intended to eventually succeed the HTML4.01 specification.


• Since the HTML serialisation of HTML5 is not an SGML or XML format, HTML5 describes this new serialisation in detail.

I’m saying this to emphasise that HTML5 is not in any way, shape or form the death of XHTML, nor is it intended to “kill off” XHTML. In fact, the next version of XHTML is going to be the XML serialisation of HTML5. The reason the HTML5 spec spends so much more time explaining the HTML format than the XML format is that the XML format is already adequately explained by the XML specification, while the HTML format is not explained anywhere else, and thus has to be explained in it’s entirety in the HTML5 specification.

Digression about the “XHTML” name

There is however the question of the “XHTML” name. One of the main goals of HTML5 is to be compatible with current content today (be that valid HTML and XHTML or invalid tagsoup). That means that the XML serialisation of HTML5 must use the XHTML1.0 namespace of “http://www.w3.org/1999/xhtml”. HTML5 cannot make any changes to the semantics within that namespace if those changes would break live content. It can, however, add semantics to that namespace.

So, to my argument: HTML5 will update and replace the vocabulary of HTML4.01. There are two serialisations of the HTML4.01 vocabulary: The SGML serialisation of HTML4.01 and the XML serialisation of XHTML1.0 and associated “http://www.w3.org/1999/xhtml” namespace for attached semantics. XHTML1.0 is , to quote the subtitle of the specification, “A Reformulation of HTML 4 in XML 1.0″. This is a direct update, and it only comes to reason that the update keeps the name of the serialisations. Further, changing this namespace is NOT an option. This namespace is absolutely required for backwards compatibility.

Also do note that the namespace contains the “XHTML” name, so it would make even less sense to change the name to something else.

XHTML2 on the other hand doesn’t have any backwards compatibility requirements, and indeed does make incompatible changes to the semantics of XHTML. It’s also, unlike the XML serialisation of HTML5, not a reformulation of HTML to XML, but a whole new language. The XHTML2 specification using another namespace than that of XHTML1.0 was not a problem the first three years and using the XHTML1.0 namespace is as far as I can see purely detrimental for adoption of XHTML2 since it makes it impossible for user agents to both support current XHTML1.0 content and new XHTML2.0 content. If you were a browser maker, and had the option to either support an old standard with much live content which also happens to correspond semantically with another format you need to support (HTML) or a new standard with very little content whatsoever, and with no choice in between, which choice would you take? I fail to see how the XHTML2 WG can even be conceived to have more right to the “XHTML” name than the XML serialisation of HTML5. If anything, they should be the ones changing the name to something other than “XHTML”, not the HTML WG.