4 ms·

That was tried 20 years ago and it turns out that humans are not good at writing XML. XML makes sense if you are authoring HTML in an editor. However, this is

That was tried 20 years ago and it turns out that humans are not good at writing XML. XML makes sense if you are authoring HTML in an editor. However, this is not how most HTML is actually produced. It's mostly produced by templating engines. This means that you can't validate the XHTML during development because it's being generated on the fly. You only find out that it's valid in testing or production, perhaps only for a subset of users in certain situations. With HTML this is OK because there is error recovery. For XHTML you get literal downtime because the entire page shows a WSOD in the worst case. Yes XHTML is okay as an internal tool, if for some reason your pipeline depends on parsing your own HTML then switching to XHTML internally could be a win. Just don't ship XHTML to browsers.

bazoom42 2y ago
Surely a template engine would be able to produce valid (X)HTML? Strict XHTML failed on the web because older browsers could not show it at all (since it used a different mime type) so nobody sane would use it. The problem wasn’t the strictness per se, the problem was how it was introduced without concern for backwards compatibility. JavaScript is strict in the sense any syntax error will terminate execution. This seems to work fine because there is an incentive to make the syntax valid. If XHTML was introduced in a backwards compatible way but new features (like canvas) only worked in strict mode, I’m sure it would have caught on. The incentives just have to be there.
- bentley 2y ago
  IE6’s refusal to display any page served with the XHTML MIME type was certainly the main reason nobody deployed real XHTML, but the overstrictness was not far behind. Hard enough to justify a complete rewrite of your website’s HTML; even harder when any encoding error or tag imbalance generated by your CMS would display the yellow screen of death rather than a best guess or even displaying everything up to the error: https://commons.wikimedia.org/wiki/File:Yellow_screen_of_death.png https://commons.wikimedia.org/wiki/File:Yellow_screen_of_dea...
  - dvdkon 2y ago
    I think if XHTML was pushed forward, the second problem would be swiftly solved: We'd have a lot more systems that considered webpages as XML documents rather than just templated text. And text-based systems could easily validate their XHTML output and report failures quickly, as opposed to now where you get a broken page and have to specifically look if your HTML isn't malformed.
  - bazoom42 2y ago
    If there was an actual benefit to using XHTML I’m sure CMS’s would be updated to support it. It is not like it is an impossible problem to produce syntactically valid JSON or SVG for example. As “use strict” in JavaScript shows, it is possible to introduce stricter parsing of an existing format, as long as it is explicit opt-in and existing content is unaffected.
    - notpushkin 2y ago
      I think the main problem with CMSes supporting XHTML would be that basically every single one uses template engine that treats HTML as a string of characters. Is there a templating system that’s easy to use (think Jinja or something Svelte-like), but parses templates as XML instead of just concatenating a bunch of strings?

bazoom42 2y ago

Surely a template engine would be able to produce valid (X)HTML? Strict XHTML failed on the web because older browsers could not show it at all (since it used a different mime type) so nobody sane would use it. The problem wasn’t the strictness per se, the problem was how it was introduced without concern for backwards compatibility. JavaScript is strict in the sense any syntax error will terminate execution. This seems to work fine because there is an incentive to make the syntax valid. If XHTML was introduced in a backwards compatible way but new features (like canvas) only worked in strict mode, I’m sure it would have caught on. The incentives just have to be there.

bentley 2y ago
IE6’s refusal to display any page served with the XHTML MIME type was certainly the main reason nobody deployed real XHTML, but the overstrictness was not far behind. Hard enough to justify a complete rewrite of your website’s HTML; even harder when any encoding error or tag imbalance generated by your CMS would display the yellow screen of death rather than a best guess or even displaying everything up to the error: https://commons.wikimedia.org/wiki/File:Yellow_screen_of_death.png https://commons.wikimedia.org/wiki/File:Yellow_screen_of_dea...
- dvdkon 2y ago
  I think if XHTML was pushed forward, the second problem would be swiftly solved: We'd have a lot more systems that considered webpages as XML documents rather than just templated text. And text-based systems could easily validate their XHTML output and report failures quickly, as opposed to now where you get a broken page and have to specifically look if your HTML isn't malformed.
- bazoom42 2y ago
  If there was an actual benefit to using XHTML I’m sure CMS’s would be updated to support it. It is not like it is an impossible problem to produce syntactically valid JSON or SVG for example. As “use strict” in JavaScript shows, it is possible to introduce stricter parsing of an existing format, as long as it is explicit opt-in and existing content is unaffected.
  - notpushkin 2y ago
    I think the main problem with CMSes supporting XHTML would be that basically every single one uses template engine that treats HTML as a string of characters. Is there a templating system that’s easy to use (think Jinja or something Svelte-like), but parses templates as XML instead of just concatenating a bunch of strings?