HTML5 could have taken the extra step of defining a canonical XML or XML-compatible DOM encoding, or at least encouraged it. But the anti-XML sentiment was explicit and spiteful. Still, popular XSLT processors are built to consume and even produce HTML5, I'm just not sure how thorough those capabilities are or whether they're based on any formal or informal standards. (Maybe the W3C has/had something like that, as part of it's attempts to rollup HTML5 snapshots into versioned standards?)
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.
> HTML5 could have taken the extra step of defining a canonical XML or XML-compatible DOM encoding, or at least encouraged it.
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.
> 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
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.
The main one is that even a slightly broken XHTML document will fail to render. HTML is much more forgiving.
With the benefit of hindsight, if the web had been that way from the beginning, I think we would have been better off. The moment you tested your content in any browser, you'd immediately see if it was broken.
But it wasn't something that could get introduced later, after all the broken content that already existed.
With all respect - the opposite is true. The web succeeded because HTML and HTTP are easy standards easily writable by humans with text editors. HTML was writable by non-programmers.
I don't think "parsed strictly" makes something hard; on the contrary, I think it's helpful to make something easy. Clear feedback, easy to test.
But then, I've always preferred strongly typed over stringly typed.
This imagines HTML as code and not markup.
The reason HTML and markdown are more widely adopted than latex is because the former are more forgiving.
I am thinking of it as markup. I stand by the point: I think "forgiving" is not a feature in parsing; it's a bug.
Forgiving is very helpful in enticing those whose content you'd like to parse to start producing content. There's no use in having the worlds greatest pipeline if nothing is being put in and moved through. See the tragedy of the death of flash and "surely someone will come along and make a great frictionless editor for canvas and webgl", only for all the creative energy ending up being sucked up and monetised by roblox, leaving the world worse off.
That's not obviously so. The adoption of JS wasn't particularly hindered by the fact that users have to match their brackets and generally avoid syntax errors.
Yeah, I think SGML HTML as the first pass was a mistake. All my early websites were XHTML until people called them "bad"...
That's what browsers at the time did. But the format could be used with a lenient parser if anyone wanted that
I'm curious, what exactly in the DOM is not XML-compatible?
From long-lost memory, I think it's implicitly closed tags (e.g. img).
XML can handle implicitly closed tags, they call them "empty" in the spec here:
https://www.w3.org/TR/xml/#sec-starttags
Empty tags in XML are not implicitly closed. They require the explicit /.
XML can handle <img /> but not <img> followed by tagsoup (like HTML handles).