W3C dumps XHTML2 to concentrate on HTML5 | Hacker News Reader

W3C dumps XHTML2 to concentrate on HTML5

w3.org

64 pointsriklomas16 comments

More like: "W3C dumps XHTML2 to concentrate on 'XHTML5' (HTML5 with XML serialization of HTML)"

Exactly.

But does anyone that matters really care about XHTML5? Seems like the "pedantics' version" of HTML. None of the major browsers seem to care about it, so why should anyone else?

Am I missing something?

(I used to follow this stuff a lot more closely.)

There are a lot more tools for manipulating XML than just for HTML. Also I gather that operating on proper XML (eg XHTML) is less resource intensive. XML has namespaces allowing inline inclusion of SVG, MathML and the like. XHTML has RDFa to provide inline metadata (semantic web stuff).

The XHTML transition seems to have failed mainly because IE6 would baulk on XML mimetypes and offer to download them instead of rendering.

This just seems to be "XHTML is dead, long live XHTML5" ?

There were a few blog posts about this a couple of months back but I held off. Looks like it's time to go back to HTML doctypes after 7 years or so. Should I be reverting to HTML?

To be really successful, XHTML requires that both authors and tool vendors get everything right, virtually all of the time. Otherwise...

* If authors get it right but tool vendors don't, XHTML offers no feature advantage.

* If tool vendors get it right but authors don't, XHTML is non-functional.

Of course, expecting the necessary level of compliance is unrealistic, especially given how complex the required stack of specs and interactions really is; actual practice so far seems to consist mostly of people ignoring the parts that are hard and so compromising the draconian processing XML was supposed to bring with it.

Well, if you were using XHTML doctype for 7 years, then you were doing it wrong. Unless you served your pages with application/xhtml+xml MIME type, that is. Otherwise no browser did use XML parser for your pages and munched them with old good HTML/tag soup parser. BTW, HTML5 lets you include MathML even in HTML serialization.

An intersting detail in the HTML5 spec is that trailing slashes like in <br /> are allowed (but ignored) in the HTML serialization. This allows you to write valid HTML5 which is at the same time valid XML.

To be fair, trailing slashes were ignored all the time. By this I mean that treated properly with MIME text/html they would produce a bunch of ">" on your page — they have different meaning in SGML from that in XML. That's one of the reasons I stuck with HTML4.01 Strict: I don't like the idea that XHTML works in browsers simply because of the miss-implementation of a standard.

good riddance, now there is no longer any dispute over which standard is the future of HTML

XHTML2 had a nice, clean design, but it never had any chance of superseding HTML since it wasn't backwards compatible.

Speaks to the power of Google. I really think they gave HTML5 a big shot in the arm during I/O.

Perhaps, but pretty much everyone with a voice in the industry has been pro-HTML5 and anti-XHTML2 for some time now.

They're still doing XHTML5

Which is not so bad, because it's based on a vocabulary people actually use.

Surely this will be a problem for XML based template engines (Lift comes to mind)?

No, HTML5 defienes an XML serialisation (aka XHTML5), and if it didn't, lift could just use a PrettyPrinter that writes HTML instead of XHTML.

Now if only they could dump XML and concentrate on JSON, that would be great progress indeed...

Reply on news.ycombinator.com