3 ms·
> they don't recover at all from errors This is a recurring argument I see against XHTML. Fundamentally I don’t see it as a downside (you don’t expect the brow
by notpushkin 2y ago
> they don't recover at all from errors
This is a recurring argument I see against XHTML. Fundamentally I don’t see it as a downside (you don’t expect the browser to run malformed JavaScript – why not HTML, too?). I agree there’s a couple of possible obstacles, though:
1. It can be hard to produce 100% valid XHTML by hand – I personally run into errors from time to time. This is actually something an LSP could help with! All these errors can be detected at authoring time, given the proper tooling.
2. Naive template systems might produce invalid XHTML if you’re not careful. Personally I haven’t run into such situations, but some people say they do.
This is also a tooling problem, but it’s a bit trickier to tackle. A solution could be either (1) an LSP for the templating system, working together with the (X)HTML LSP, or (2) a templating system that is XML-native (but more ergonomic than XSLT haha).
(Personally, I’m thinking about starting something like (2) with Jinja-like syntax, but I feel it’s not something I have the time or energy for, at this point.)
> when really, they should show an annoying popup and then switch to a quirks parser
Not sure if it’s a good solution long-term, but I see how that could help with adoption, so I’m all for it.
- wizzwizz4 2y ago> you don’t expect the browser to run malformed JavaScript Refer to https://tc39.es/ecma262/2024/multipage/ecmascript-language-lexical-grammar.html#sec-automatic-semicolon-insertion https://tc39.es/ecma262/2024/multipage/ecmascript-language-l... (extract below) --- In contrast, the source { 1 2 } 3 is also not a valid ECMAScript sentence, but is transformed by automatic semicolon insertion into the following: { 1 ;2 ;} 3; which is a valid ECMAScript sentence.
- notpushkin 2y agoThat's a weird wording, huh. I would interpret it not as yeah this is invalid code but we fix it for you, but rather this code would be invalid if not for this weird exception we carve out for it. I would love to say “let's abolish ASI too”, but (1) some folks genuinely use it assuming that it's a syntax feature and not a compat thing, and (2) it's a compat thing, meaning it's not getting removed without a very valid reason. A shame, though. But JS parsing is still undeniably way more strict than HTML, no?
- wizzwizz4 2y agoHow about Appendix B? https://tc39.es/ecma262/2024/multipage/additional-ecmascript-features-for-web-browsers.html https://tc39.es/ecma262/2024/multipage/additional-ecmascript... > These features are not considered part of the core ECMAScript language. Programmers should not use or assume the existence of these features and behaviours when writing new ECMAScript code. ECMAScript implementations are discouraged from implementing these features unless the implementation is part of a web browser or is required to run the same legacy ECMAScript code that web browsers encounter. Some of these are legacy APIs, but some of them are just plain syntax errors.
- jancsika 2y agoInterviewer: "So what's your professional opinion about this annoying popup that blocks the main thread?" Interviewee: "I see how that could help with adoption, at least until we are able to migrate to a red single-line error with a long-ass-scrollbar that displays instead of rendering any of the page at all." Interviewer: "Thanks. We'll be in touch."
- notpushkin 2y agoI'm assuming it's just a joke for the sake of joke, but please re-read my and GP's comments again. This is not a solution we're discussing. > Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes. > Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. – https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html