Did you close that tag in that textarea from some third party content? If not you're whole view is broken. It was a layer or hopeful standardization that was too hopeful and counted on implementers too much to be exact. It was a nice attempt but was quickly retracted to go to HTML5.
I guess the same thing applies to HTTP/2, sometimes you have to dumb/simplify it down a little, the smartest way that relies on implementers, might be the leap that is too hard to make. The best standards are the simple ones that cannot be messed up even by poor implementations. Maybe the standards for protocols developed in the past looked at adoption more as they had to convince everyone to use it, here if you force it you don't need to listen to everyone or simplify, which is a mistake.
While code and products should be exact, over the wire you need to be conservative in what you send and liberal in what you accept in standards and interoperability land.
In another area, there is a reason why things like REST win over things like SOAP, or JSON over XML, it comes down to interoperability and simplicity.
The more simple and interoperable standard will always win, and as standards creators, each iteration should be more simple. As engineers, we have accepted the role of taking complexity and making it simple for others, even other engineers or maybe some junior coder that doesn't understand the complexity. What protocol is the new coder or the junior coder going to gravitate to? The simple one.
It was better, from an engineering aspect it should have been better and the world would have more precision and validity/verification on content.
But from an interoperability aspect (relying on implementations) the market didn't think it was better or we'd be using it still. HTML5 won because it was simple and met many needs demanded by the market.
The simple standards that provide more benefits, but most importantly are highly focused on interoperability and simplicity, win, always, even if they seem subpar from an exactness standpoint.
At one point in time SOAP had the same religious hype surrounding it that HTTP/2 seems to have. But sometimes you have to take a step to realize you are slightly off path according to the market, not what you might want to design and what should win but what happens with interoperability in the market. HTTP/2 and XHTML type standards are steps, to something better but are too top down or ivory tower eventhough they have lots of awesome and needed features.
HTML5 is a mix of XHTML and HTML4, but with new features. Its syntax ressemble more XHTML than HTML and as thus it is more XML compliant, although you can ignore strict syntax [0]. HTML5 is both XHTML and HTML4 alike, so it is no surprise that is has taken over the market.
Note that I don't especially like HTTP/2 and believe that a hack like SPDY should not make it to a standard. More time and care should be made to make a central protocol like HTTP (central in that it is used alot).
Technically HTML was a derivative of SGML. That said, as someone who did a fair amount of parsing of old-timey HTML...it would have been really nice if it was XML.
Well, by the time the first spec was written it was defined to be an SGML application; when TimBL first implemented it, it was "roughly based on SGML". As far as I'm aware, except for the W3C Validator, no other serious HTML implementation treated HTML as SGML.
And it couldn't have been XML, because HTML predates it.
I guess the same thing applies to HTTP/2, sometimes you have to dumb/simplify it down a little, the smartest way that relies on implementers, might be the leap that is too hard to make. The best standards are the simple ones that cannot be messed up even by poor implementations. Maybe the standards for protocols developed in the past looked at adoption more as they had to convince everyone to use it, here if you force it you don't need to listen to everyone or simplify, which is a mistake.
While code and products should be exact, over the wire you need to be conservative in what you send and liberal in what you accept in standards and interoperability land.
In another area, there is a reason why things like REST win over things like SOAP, or JSON over XML, it comes down to interoperability and simplicity.
The more simple and interoperable standard will always win, and as standards creators, each iteration should be more simple. As engineers, we have accepted the role of taking complexity and making it simple for others, even other engineers or maybe some junior coder that doesn't understand the complexity. What protocol is the new coder or the junior coder going to gravitate to? The simple one.