It is pretty funny to defend Apple (or any other browser vendor) using the argument that standards are unfinalized. Running living standards was the coup done by WHATWG, a.k.a. browser vendors.
Darn it, XHTML could have been so good if it got mass adoption! It would simplify parsing content and personally, working with XHTML is sane and easy (albeit in a somewhat dated Java stack with JSF/PrimeFaces, which build upon it). It also gets rid of the inconsistent tags in HTML which can remain open, which i think is a good thing.
Then again, i also like XML, maybe to the point of sometimes preferring it over JSON (or at i would if the ecosystem would be there - WSDL was leaps and bounds ahead of OpenAPI/Swagger, but seems like the interest in XML died down), so i don't doubt that many don't feel that way about all of it.
I wasn't going there, but then with such an interesting reply I might.
XHTML's complexity is too much to deal with and the WHATWG is going to keep all this unnecessary stuff out so you won't lose control to generalized tools like an IDE and systems that favors formally educated language/tool writers, i.e. schema validators and, as we see now, transpilers.
The end result is still everyone using an IDE perhaps due to more irregular features after WHATWG encouraging a framework, but at any rate demonstrating XHTML was not the real source of webmaster stress and future angst.
So now you have more complexity, a still pointlessly irregular format that needs to identify it's magical elements, and, (to get back on topic,) features that must be implemented first in 2 browsers to become standard.
All of this is brought to you by employees of Apple and the other vendors. If WebKit isn't one of the 2 implementations most people choose to work with when pushing a standard then Safari is the dead implementation due to a constellation of choices all made with Apple's support and approval.
XML is pretty much alive in the .NET and Java ecosystems.
But I think for most people it is in general a bad idea. XHTML parsed as XML means that anything that mashes together strings to generate a webpage, like much of webdev, is prone to generating invalid XML due to bugs in the code, and this in turn leads to catastrophic failure where the page doesn’t just have errors but fails to render entirely. During the period where people were swayed by the XHTML proponents’ arguments it was commonplace for me to visit a website and see only an XML parsing error.
XHTML parsed according to custom rules that are forgiving for errors yet consistent and straightforward to implement would have been a good idea, but nobody implemented it to my knowledge. Luckily HTML5 does specify such a forgiving parsing system, where pretty much any random sequence of bytes can be parsed consistently.
Just because Chrome rammed some of its internal API through standards bodies, released it in stable, and called it a standard, does not a) make it a standard, and b) mean that other browsers should rush to implement it. No matter how many HN commentators think otherwise.