4 ms·
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
by Thiez 5y ago
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.
- heavenlyblue 5y agoExplain to me why XHTML did not stay with us?
- tomtomtom777 5y agoIt 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.
- coldtea 5y agoBecause nobody cared much for it, and it didn't give us what we actually wanted, which HTML5 did...
- magila 5y agoXHTML 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.
- jcranmer 5y agoIt 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).
- nyanpasu64 5y agoHTML5 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-mutation-dompurify-2-0-17-bypass/ https://research.securitum.com/mutation-xss-via-mathml-mutat....
- masklinn 5y agoBig 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.