Hacker News Reader

Comment by Thiez | Hacker News Reader

I would disagree. For example, suppose we enforced XHTML. Even though it's a mostly dead standard that was never very popular, there are plenty of free and very functional validators around. You don't need to be a multi-billion dollar company to close your tags.

Similarly for JS, strict mode did not ruin the internet. Sure, there is a lot of old JS code around that may or may not run in strict mode. That is not because it is any harder to write correct JS in strict mode than it is in "sloppy" mode, but the "robustness principle" has just burdened us with a lot of legacy crap that wouldn't otherwise exist. I would argue that the web would be better if JS had been strict from the start.

View on HN

Big differences between xhtml and js-strict are:

- strict mode is a much more local opt-in, it’s difficult to opt others into strict mode, and thus the likelihood of respecting strict mode is high

- js is much less subject to embeddings, with xhtml even back then there was a long tail of CMS type content which would suddenly break the page hard and with no actionable recourse for the viewer

- finally strict mode came with a bunch of benefits e.g. new syntax / constructs, etc, for the person opting into strict mode, but unless you were an XML-head with an entire XML-based processing pipeline, what did XHTML give you? Additional pain when authoring content is about all.

Explain to me why XHTML did not stay with us?

XHTML never really had a chance because the dominant browser at the time, Internet Explorer, never supported it. Since people were going to have to deal with all of IE's quirks anyways there was little appetite for putting in the effort to support XHTML too.

It didn't survive because HTML5 came along with very well defined and strict parsing rules.

You don't need closing tags for a specification to be strict. As long as you define the parsing rules rigorously as HTML5 does, there is little benefit in XML compliance and there is in a well defined non-XML standard as it is mostly backwards compatible.

It depends on what you mean by 'XHTML.'

One of the possible definitions is a mode of HTML that was forced to be strictly validating by an XML parser. Adoption of this was hurt by the fact that XHTML-delivered-as-XHTML didn't work correctly in the dominant browser of the time. But HTML5 also delivered a fully-specified parser that explained how to handle tag soup correctly, which meant the problem trying to be solved here (having to parse HTML files into a DOM) was solved in a different way.

Another possible definition is the XHTML 2.0 definition, which tried to rip out a lot of HTML features and replace them with more semantic definitions and was largely an effort that was entirely divorced from reality (to the point of driving out the web browser implementors entirely from the working group).

HTML5 rules didn't solve the problem of parsing HTML files into a DOM. Instead it mandated the existence of HTML files which, when parsed, converted to HTML, and parsed again, produce a different tree than the first time around. This harmful property can be used to develop XSS exploits like https://research.securitum.com/mutation-xss-via-mathml-mutat....

Because nobody cared much for it, and it didn't give us what we actually wanted, which HTML5 did...

Reply on news.ycombinator.com