3 ms·

> That’s the worst possible way to define a standard. Not for the web. You can't break the web, so you can't be stricter that what has already shipped. Sorry.

by Touche 10y ago

> That’s the worst possible way to define a standard. Not for the web. You can't break the web, so you can't be stricter that what has already shipped. Sorry. To your general point; I don't care. I don't want to use tools that are incompatible with what browsers do, and what browsers do is defined by WHATWG HTML, not w3c.

kuschku 10y ago
Well, then stop using curl, cause that’s not compliant with the WHATWG standards. > Not for the web. You can't break the web, so you can't be stricter that what has already shipped. Sorry. Yes, you can, and yes, you have to. You’re doing a dangerous tradeoff, sacrificing long-term usability for your marketshare numbers in the next 3 months. If you want to allow everyone to write a parser able to parse websites, or allow everyone to be able to write websites, then you have to replace and deprecate parts of the web. In fact, Google does that all the time with Chrome. "HTMLMediaElement can not be controlled on Chrome Mobile, unless your code is running in a click handler, to prevent autoplay". "GeoLocation API will not be available through HTTP" "We will not support HTTP sites in the future" "We will not allow websites to connect to ports that are on our blacklist, including any port below 1024 that’s not 80 or 443, or any port used for IRC or other services" So, yes, you can be stricter than what has already shipped. So when can we finally fix all the other issues in the web?
- gsnedders 10y ago
  Breaking 0.03% of the web is one thing, breaking larger parts of it starts to have far more dramatic effects. Many of the "worst" parts of the web are some of the most pervasive: well over 90% of the web relies on non-conforming HTML being parsed, much of the non-English speaking world relies on some of the really whacky behaviour around URL serialisation/parsing with different encodings, etc.
- om2 10y ago
  > If you want to allow everyone to write a parser able to parse websites, or allow everyone to be able to write websites, then you have to replace and deprecate parts of the web. Sounds good in theory. In practice, the opposite is true. Attempts to define HTML syntax strictly (like DTD-based HTML 4 and earlier, or like XHTML) result in parsers that can't parse websites. But the WHATWG definition of HTML parsing, with its exhaustive and specific attention to handling of error cases, has resulted in HTML parser libraries that are compatible with the actual web. Before that, only browsers could parse real websites as intended and they could only do it through reverse engineering and guesswork.
  - kuschku 10y ago
    > Attempts to define HTML syntax strictly (like DTD-based HTML 4 and earlier, or like XHTML) result in parsers that can't parse websites. That’s a good thing. Because it means websites will be forced to fix their shit, or be broken. Browsers should start with a strict parsing standard, and color the addressbar in a warning red on every page that doesn’t fulfil it. After a year or two, remove support for non-strict parsing piece by piece, until a strict situation is the result. You don’t see WebAssembly parsing everything that’s possible either. And JavaScript parsers trying to make sense of nonsensical content also haven’t been a thing in years. In fact, the exact same thing happens with language all the time: A standards body decides to standardize part of the language, and simplify it, and then new grammatical rules are written, and enforced by law in education, and kids learn the new rules that make everything simpler. A few years later, everyone has adapter – you don’t see anyone using pre-2006 German anymore, either. If we can do it with fucking language, we also can do it with the web.

by Touche 10y ago

kuschku 10y ago

Well, then stop using curl, cause that’s not compliant with the WHATWG standards. > Not for the web. You can't break the web, so you can't be stricter that what has already shipped. Sorry. Yes, you can, and yes, you have to. You’re doing a dangerous tradeoff, sacrificing long-term usability for your marketshare numbers in the next 3 months. If you want to allow everyone to write a parser able to parse websites, or allow everyone to be able to write websites, then you have to replace and deprecate parts of the web. In fact, Google does that all the time with Chrome. "HTMLMediaElement can not be controlled on Chrome Mobile, unless your code is running in a click handler, to prevent autoplay". "GeoLocation API will not be available through HTTP" "We will not support HTTP sites in the future" "We will not allow websites to connect to ports that are on our blacklist, including any port below 1024 that’s not 80 or 443, or any port used for IRC or other services" So, yes, you can be stricter than what has already shipped. So when can we finally fix all the other issues in the web?

gsnedders 10y ago
Breaking 0.03% of the web is one thing, breaking larger parts of it starts to have far more dramatic effects. Many of the "worst" parts of the web are some of the most pervasive: well over 90% of the web relies on non-conforming HTML being parsed, much of the non-English speaking world relies on some of the really whacky behaviour around URL serialisation/parsing with different encodings, etc.
om2 10y ago
> If you want to allow everyone to write a parser able to parse websites, or allow everyone to be able to write websites, then you have to replace and deprecate parts of the web. Sounds good in theory. In practice, the opposite is true. Attempts to define HTML syntax strictly (like DTD-based HTML 4 and earlier, or like XHTML) result in parsers that can't parse websites. But the WHATWG definition of HTML parsing, with its exhaustive and specific attention to handling of error cases, has resulted in HTML parser libraries that are compatible with the actual web. Before that, only browsers could parse real websites as intended and they could only do it through reverse engineering and guesswork.
- kuschku 10y ago
  > Attempts to define HTML syntax strictly (like DTD-based HTML 4 and earlier, or like XHTML) result in parsers that can't parse websites. That’s a good thing. Because it means websites will be forced to fix their shit, or be broken. Browsers should start with a strict parsing standard, and color the addressbar in a warning red on every page that doesn’t fulfil it. After a year or two, remove support for non-strict parsing piece by piece, until a strict situation is the result. You don’t see WebAssembly parsing everything that’s possible either. And JavaScript parsers trying to make sense of nonsensical content also haven’t been a thing in years. In fact, the exact same thing happens with language all the time: A standards body decides to standardize part of the language, and simplify it, and then new grammatical rules are written, and enforced by law in education, and kids learn the new rules that make everything simpler. A few years later, everyone has adapter – you don’t see anyone using pre-2006 German anymore, either. If we can do it with fucking language, we also can do it with the web.