← Back to context

Comment by wahern

3 hours ago

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.