4 ms·

> Browsers HTML and CSS parsers are incredibly generous in what they accept Yes, that is part of the problem. Parsers should be fail-fast and deterministic, th

by Aaargh20318 4y ago

> Browsers HTML and CSS parsers are incredibly generous in what they accept Yes, that is part of the problem. Parsers should be fail-fast and deterministic, this is one of the many problems of the web. Developers don't notice their incorrect code due to this and without noticing rely on the implementation-specific way one browser handles the issue. Then 3 versions later or in a different browser they whole house of cards comes tumbling down. > One developer can do with the web what 10 couldn‘t do with native Building a non-trivial app is always faster to do native. By a huge margin.

chucksmash 4y ago
> Parsers should be fail-fast and deterministic, this is one of the many problems of the web. Developers don't notice their incorrect code due to this and without noticing rely on the implementation-specific way one browser handles the issue. This was XHTML documents when sent with the correct Content-Type. "Just don't display anything if the document is malformed" is worse for users if devs still create malformed documents.
- Aaargh20318 4y ago
  The only reason developers write malformed documents was because they can get away with it. And yet, millions of lines of code are written every day in programming languages that absolutely do not accept malformed code, and that all works out just fine. Another problem with it is that everyone who can get something to display in their browser suddenly thinks of themselves as a developer.
  - chucksmash 4y ago
    How does such a system reconcile the need to be opt-in to maintain backwards compatibility with the web as it exists with the likelihood that the audience you want to reach (developers who can't be bothered to Do It Right) are just the ones who will not opt in? Ancient history now, but HTML5 was developed by WHATWG specifically as pushback against priorities of W3C at time (chief among which was push for XHTML). That's not to say things cannot be improved, just to say this has all happened before and it will all happen again (and it is worth paying attention to what happened last time).
cxr 4y ago
> Parsers should be fail-fast and deterministic Raise your hackles about the choice not to fail fast if you want, but when they fail, they do fail deterministically. It's a too-common myth that they don't. (A little perverse that people who make a big deal out of others unable to follow spec, but by doing so prove they haven't checked what the spec says—because if they did, they'd know this...)
deleted 4y ago
[deleted]

chucksmash 4y ago

> Parsers should be fail-fast and deterministic, this is one of the many problems of the web. Developers don't notice their incorrect code due to this and without noticing rely on the implementation-specific way one browser handles the issue. This was XHTML documents when sent with the correct Content-Type. "Just don't display anything if the document is malformed" is worse for users if devs still create malformed documents.

Aaargh20318 4y ago
The only reason developers write malformed documents was because they can get away with it. And yet, millions of lines of code are written every day in programming languages that absolutely do not accept malformed code, and that all works out just fine. Another problem with it is that everyone who can get something to display in their browser suddenly thinks of themselves as a developer.
- chucksmash 4y ago
  How does such a system reconcile the need to be opt-in to maintain backwards compatibility with the web as it exists with the likelihood that the audience you want to reach (developers who can't be bothered to Do It Right) are just the ones who will not opt in? Ancient history now, but HTML5 was developed by WHATWG specifically as pushback against priorities of W3C at time (chief among which was push for XHTML). That's not to say things cannot be improved, just to say this has all happened before and it will all happen again (and it is worth paying attention to what happened last time).

cxr 4y ago

> Parsers should be fail-fast and deterministic Raise your hackles about the choice not to fail fast if you want, but when they fail, they do fail deterministically. It's a too-common myth that they don't. (A little perverse that people who make a big deal out of others unable to follow spec, but by doing so prove they haven't checked what the spec says—because if they did, they'd know this...)

deleted 4y ago

[deleted]