HTML5 may end up giving us real, working XHTML
Here is a thesis: the potential success of HTML5 is the web's best chance to get XHTML (in some version, in this case 'XHTML5') in a usable form.
In theory, XHTML 1.0 was just an XML serialization of HTML 4. In practice, this never was the case; there were real semantic changes between HTML 4.01 strict and XHTML 1.0, things that the XHTML people just couldn't resist changing. This meant that supporting XHTML 1.0 required real work in browsers; you could not just de-serialize XHTML into the same internal format as you used for HTML 4.01 and treat it as such afterwards.
However, there is no semantic difference between HTML5 and XHTML5; they really are the same thing being serialized in a different way (partly because both forms are being specified in one go, by the same standards group). This makes it much easier for browser vendors to support XHTML5; if you can handle HTML5 you can handle XHTML5 (and if you can handle HTML 4.01 you can pretty much handle HTML5). This means that, at least in theory, all that browsers need to do to support XHTML5 is to enable XML de-serializing.
(Now, I have to admit that I suspect that XML de-serializing is not trivial in real browsers. XML allows a wide variety of games to be played with namespaces and the like, plus strict XML error handling likely has unpleasant implications for what you can do to start processing an XHTML5 web page before you've received all of it and thus can verify that it is indeed well-formed.)
|
|