I lost any enthusiasm for XML after my experience with WDDX and XML-RPC, but as a foundation for HTML it was the best thing going. And maybe still is, given the absence of cross-toolchain contenders? Ditto for XSLT, at least if disregarding the choice to make the syntax homoiconic. In fact I circled back to XSLT long after it was clear it was a dead end. A good tool is a good tool, and the fact it remains so despite the wanton neglect only proves it.
If you make a mistake and use incorrect syntax in html, the browser will do its best to recover. In xhtml, it would just completely fail. Which approach is better is debatable.
Yeah and then we could have called it xhtml5. Too bad that does not exist. Oh wait https://html.spec.whatwg.org/multipage/xhtml.html
> But the anti-XML sentiment was explicit and spiteful.
No, 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?
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 />
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!
It might actually work if reintroduced these days as long as we can consider many components to be valid documents.
Sure there is some embedded JS in there as well but ignore that and JSX is thr XHTML comeback story.
I suppose the important part was that jsx needed to be compiled, which means it couldn't introduce any new security issues…
Client-side XSLT was always pretty useless, but I dont see what HTML5 has to do with it?
The only real use case for client-side XSLT was for styling/layout back before CSS became widely supported. Improvements in CSS support made XSLT unnecessary.