> xhtml was just a bad idea creating tons of problems and solving none.
Well an XHTML parser (and serializer) is a lot simpler, which is a pretty meaningful problem to solve.
What problems does xhtml create?
Well an XHTML parser (and serializer) is a lot simpler, which is a pretty meaningful problem to solve.
What problems does xhtml create?
Perhaps, but a combined html and xhtml parser is more complex than just a html parser. Since html already is entrenched, xhtml would be in addition to html, not instead of.
HTML has special rules depending on the tag's type, ie a bunch of them are just written (<img>) and the parser doesn't even really want to see a matching closing tag, or tags like <script> that has a special mode that stops being a HTML parser up until </script> is found. (1)
A HTML parser can become a XML parser by disabling a bunch of special-features and supporting self-closing tags (depending on XML level).
A XML parser needs a ton of "hacks" to become a HTML parser.
Also browsers needs an XML parser anyhow to support svg that's an xml-based format, also the DOM spec is written to support namespaces's like XML.
XSLT did complicate things, and most importantly it seems many relied on that one old implementation written in the 90s that was a swiss-cheese when it came to security concerns that nobody wanted to spend money on maintaining.
(1): https://html.spec.whatwg.org/multipage/parsing.html#script-d...
Even if this was true it would still increase complexity to have two parsing modes compared to just a html parser.
Whether that kind of backwards-incompatible breakage would ever become acceptable is a completely different story. But we ditched Flash, ActiveX, Silverlight, and Java applets, so who knows what could have been!
But it wasn't something that could get introduced later, after all the broken content that already existed.
But then, I've always preferred strongly typed over stringly typed.
The reason HTML and markdown are more widely adopted than latex is because the former are more forgiving.
Once there was a standardized interpretation for malformed html, there was a chance that we could have treated that as a transparent conversion layer to xhtml. That isn't how WHATWG went, however.
But I don’t think the ambiguous html parsing made it easier. If anything it made it more difficult since you had to test in multiple browsers. Eg a table which was not properly closed would render in IE but not render in Netscape.
Congratulation on reinventing HTML.
XHTML5 sort of gets us there, but parsing in standard HTML5 mode still won't do the right thing with eg <b />