← Back to context

Comment by bazoom42

8 hours ago

> 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.

XML/XHTML is a fairly strict language syntax wise compared to HTML, tags are either explicitly self-closing i.e. <img/> or terminated with a matching closing-tag, no exceptions.

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...