Interesting to see the use of HTML serialization instead of the usual XHTML stuff.
I've been going the HTML 4 (and now HTML5 with HTML serialization)route because I don't send pages as application/xml or whatever it should be. But it often means dicking with this or that tool or framework that bought into the previous future-proof technology, XHTML.
Just a note: the MIME type does not NEED to be application/xml. There is a big difference here: text/html will tell the browser "Hey, try to render this page. If something doesn't work do your best." 99% of web pages out there do this. application/xml tells the browser "Treat this as XML. If it's not valid, throw an error and quit." Naturally, most people are shying away from this option since one little mistake can make your entire website unusable.
Agreed. However, if you are not sure that every single bit of code in your application produces valid HTML then you are much safer with the text/html MIME type. As for the SGML vs XHTML debate, I'd rather not get into that since the whole thing got a bit religious at this point.
Basically, the spec says, for example, that HTML5 has an 'html' element, and it may contain a 'head' and a 'body' element. (I'm winging it here.) And the 'head' element may optionally contain one or more 'meta' elements with attributes ... whatever.
So far so good; the spec defines the structural items. But it also says, look, you can manifest, or serialize, this using XML (i.e. XHTML) syntax, in which case you need to have true, proper XML (and that means, for example, that empty elements such as 'meta' or 'br' must be closed, typically using the ' />' stuff). Or you can use HTML syntax, in which case there are a set of empty elements ('meta', 'br', 'img', for example) that do not need an end tags or that ' />' thing.