== 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
XHTMLMasochism]] 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.)