XHTML was a failure, rejected and ditched.
So if it lost data interchange and layout/interface specification... what is XML's relevancy (not counting legacy interaction/systems)?
Google, who cares deeply about their search moat, did not want easily parsable documents that revealed the wealth of underlying data to machines. It might have made it too easy to mine documents and present search results that answered common factual queries.
Also, by forging ahead with landing nonstandard feature after feature in Chrome, they were able to bleed away Firefox market share and bend the web to their will.
The only mistake XHTML made was the mime type requirement.
For this to happen, a webpage has to be served with an XML Content-Type by the server—specifically, application/xhtml+xml. HTML documents are served with a Content-Type of text/html. If you write a page entirely in valid XHTML markup, but serve it with an HTML media type, the browser treats it not as XML, but as invalid HTML, like any other tag soup, and turn it into something approximating what you meant.
However, some browsers couldn’t handle application/xhtml+xml, and would simply prompt a download dialog for the page rather than displaying it. Well, one browser did that. You know the one… Internet Explorer. Because support for the new media type wasn’t widespread, the W3C allowed serving XHTML 1.0 pages as text/html as a transitional mechanism. They wouldn’t get any of the “benefits” of XML parsing (like the YSOD), but they’d display in IE. XHTML 1.1 and the stillborn 2.0 were required to be served as application/xhtml+xml, and thus saw only the barest minimum of adoption. As transitional mechanisms are wont to do, XHTML 1.0‐as‐text/html stuck around, W3C’s reputation took a blow, and WHATWG seized the reins, codifying browser practices into what’s now known as HTML5.
Incidentally, this is the origin of the space everybody puts within a self‐closing tag. An XML parser would see no difference between “<br/>” and “<br />”, but some tag soup HTML parsers of the time did. The XHTML spec had an appendix dedicated to these compatibility tricks that were solely needed because people were serving pages with the only Content-Type that IE understood. https://www.w3.org/TR/xhtml1/#guidelines
Before that it was more "undefined" behavior than "illegal" as older HTML specs simply didn't consider it.
Why not? AFAIK it worked well. See SAP and many other products.
I'd say the immediate thing that comes to mind is that there isn't a one-line-code that would deserialize an XML message to language-universal collections (arrays/lists/vectors, dictionaries/hashmaps/assoc. arrays). The closest was XStream in java-land, which I used heavily before JSON became widespread.
Secondly, it doesn't have a natural specifier for THIS IS A LIST. You're guessing or relying on mappers/marshalling to produce such things, while JSON can naturally map from JSON to an object graph without excessive mappers, annotations, etc.
Other complaints: The attribute/tag dual-duty was also problematic, confused the entire problem space.
The complexity of XML features (namespaces and bunch of other standards) is hidden in libraries. And some of those features might be useful, only to be re-implemented in JSON, with same amount of additional complexity in libraries.
Just recently I used lxml in Python to parse RSS and it gave me collection like if I used json module. Moreover, I used XPath extensively to pick parts of the XML I was interested in. This would have been more complex with manual traversal. Of course there are Python bindings to jq, but in general the jq language isn't as widespread as XPath. Then there's the slight annoyance of accessing attributes via dedicated getter methods as they're "special" as you mention. But in all, I haven't noticed millions of lines of extra code and complexity.
The big thing I'd be curious about is what happens when new features are added: do they get added to the XHTML parsers as well or does that become a legacy path drifting behind the main web platform? I believe there were already some issues with Chrome along those lines when they added JS modules, for example.
Also, most browsers today no longer support XHTML 1.x "Strict" modes, the errors they surfaced, and instead just laxly parse all XHTML 1.x with the same parsers they use for "HTML5". (IE11 I believe was the last browser with XHTML "Strict" support and used a proper XML parser and error reporting when parsing XHTML.)
[1] Outside of how XHTML 2.0 influenced HTML5's list of "semantic DIVs" the tags like ARTICLE and SECTION that don't have any meaningful semantics in current browsers but are nice when you get bored of surrounding everything in DIV. XHTML 2.0's standard attached actual meanings to those tags and had a lot of specified behavior for how those tags would operate. The only surviving "tag behavior" from XHTML 2.0's plan was DETAILS, I believe. I also believe the exact lists of tags are disjoint and XHTML 2.0 had tags that didn't even make into the official "semantic DIV" bucket, are out of spec in HTML5, but HTML5 browsers will mostly just ignore and fallback to treating unknown tags as fallback DIVs anyway.
And fixed: https://vbezhenar.com/test-valid.xhtml
It works in Chrome for me, parsing failed as expected on the invalid file. Also you can't use document.write from JS, so DOM has special treatment for XHTML as well.