> a more-robust strict subset of the formal HTML spec
I still think we’d be better off just using XHTML. There are some practical problems with XHTML5 (e.g. there’s no named entities support for some reason), but the syntax makes sense at least.
I still think we’d be better off just using XHTML. There are some practical problems with XHTML5 (e.g. there’s no named entities support for some reason), but the syntax makes sense at least.
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.
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.
https://commons.wikimedia.org/wiki/File:Yellow_screen_of_dea...
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.
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?
Many of the "problems" with HTML are still handled adequately simply by using a spec-compliant parser instead of regular expressions, string functions, or attempting to parse HTML with XML parsers like PHP's `DOMDocument`.
Every major browser engine and every spec-compliant parser interprets any given HTML document in the same prescribed deterministic way. HTML parsers are't "loose" or "forgiving" - they simply have fully-defined behavior in the presence of errors.
This turned out to be a good thing because people tend to prefer being able to read _most_ of a document when _some_ errors are present. The "draconian error handling" made software easier to write, but largely deals with errors by pretending they can't exist.
(I’d also like a word with yaml while we’re at it…)