[hackrmn]

I agree we shouldn't have thrown the baby out with the bathwater -- and it's not like _strictness_ was not in XML's spirit, so your usual suspects for primitive types -- numbers and booleans, to name a few -- _could_ have been an improvement along the XML's path of evolution. But something tells me that these features only open a door to more features that are needed. The bounds on what constitutes the [sufficient] set of fundamental types, is a hard problem to solve, especially if it cannot be extended through itself (composite/compound types). XML had not anything but strings for attribute type, but that also made it simple and kept it away from the domain of type theory and parsing more than it already had to have parsed. So I am undecided, but I liked the "one good feature of HTML 5" part of your comment, so I took your bait ;-)

XHTML, as has been _repeatedly_ mentioned by multiple people -- a thing that comes again and again -- at least was _strict_ in that your malformed document told you _early_ (or, rather, a compliant XML user agent did, like your Web browser), where with HTML it's your users that find out, except they have no clue what's going on -- they know even less about HTML 5 parser than the author does, staring at something that should have been a list item but becomes a table cell element or some such.

If HTML 5 is indeed not even used directly, that makes the argument for the _stricter_ format like XML-based XHTML even more attractive -- machines do much better with strict bounds than humans do, so if humans aren't writing HTML, then it feels like we've been sold on the wrong premise, even if retrospectively.

[notnullorvoid]

Boolean attributes are less about types and more about syntax convenience IMO, even HTML treats them as empty strings. <tag attr> is a shorthand for <tag attr="">, which then in your program you can decide if some attributes should handle empty strings as a truethy value. Some cases like <person name> the program would still make sense to treat it as an empty string.

> If HTML 5 is indeed not even used directly, that makes the argument for the _stricter_ format like XML-based XHTML even more attractive

True however those who control the HTML spec are unlikely to let it go. Since XHTML has been treated as effectively deprecated some feature like incremental document streaming do not work in XHTML, this makes it unlikely for libraries that abstract away HTML to adopt XHTML as a target.

[hackrmn]

Right, if what you mean is making the `=""` optional, then it seems even more attractive than types, I admit. You'd have to amend the XML grammar to see if making the `=""` optional introduces problematic (for e.g. the reference parser) ambiguities that weren't there before. From the looks of it / intuitively it doesn't seem to be the case, but with a language that's deployed in a gazillion places such small changes rightfully warrant new major revision, which would be XML 2, I guess. Which would have wide ramifications, I imagine. Which brings me to W3C....

> True however those who control the HTML spec are unlikely to let it go.

Like I said in another comment, I believe XHTML was axed because it stepped on _someone_'s toes. I suspect it had to do with W3C being understaffed and criticised for being too slow at the time -- by most of the industry, and most of it deservingly -- and WHATWG (with Google co-authoring their standards) stepping in as the authority on all things Web, and somewhere between the two XHTML was used as the proverbial fall guy. Speculation, of course -- but a lot of good, useful work was thrown out the window with XHTML. Not the first time it happens, of course, but this was the Web we're talking about, not Adobe's product portfolio.

I've heard the "streaming" argument before, by the way -- it keeps being mentioned (probably because it was one of the official reasons for the transition to HTML 5), but I think it's a "ruse" -- nothing about XHTML in practice prohibits an agent from progressively rendering an XHTML document, and if something really did, in W3C's writing for instance, then all they needed to do is relax that requirement because again -- there's plenty of hierarchical data formats with strict rules that by their very nature don't preclude parsing (or semantic analysis / rendering) done in streaming fashion.