5 ms·

Right, everything is relevant to someone. But the grandparent was talking about what is relevant to browser vendors (and thus web developers), in which case it'

Right, everything is relevant to someone. But the grandparent was talking about what is relevant to browser vendors (and thus web developers), in which case it's pretty clear.

andrewmcwatters 10y ago
There are developers who solely rely on W3C recommendations to implement renders, parsers, and other standards-conforming mechanisms, widely because they provide actual versioning rather than a living standard. How clear this is to actual implementors is a matter of debate and preference.
- Touche 10y ago
  Can you list some of these tools so that I can avoid using them, as they likely contain bugs that are fixed upstream in whatwg/html?
  - kuschku 10y ago
    WHATWG is a bug. A set of browser vendors just choosing the maximum superset of their implementations for everything. Everything is compatible. That’s the worst possible way to define a standard. A standard is important because it sets limits of what is allowed and what not. Because it is more strict than anything that came before. Because you can actually just implement it, and if something doesn’t work, you can complain to whoever didn’t follow it. The A paper standards say "A ratio of 1 to sqrt(2), A0 is 1m², every smaller standard is exactly half the area of the previous one". Not "Well it’s kinda this or that or that", as WHATWG does. The fight where WHATWG was trying to redefine what URL means, and tried to force cURL and other projects to parse completely retarded patterns as "http:/google.com" (notice the typo) as URL is just another example. As I said in another comment, a standard is supposed to shape the environment it describes, make it simpler. WHATWG standards don’t fulfil that description, they make the web just more complicated than it already is.
    - 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.

Right, everything is relevant to someone. But the grandparent was talking about what is relevant to browser vendors (and thus web developers), in which case it's pretty clear.

andrewmcwatters 10y ago

There are developers who solely rely on W3C recommendations to implement renders, parsers, and other standards-conforming mechanisms, widely because they provide actual versioning rather than a living standard. How clear this is to actual implementors is a matter of debate and preference.

Touche 10y ago
Can you list some of these tools so that I can avoid using them, as they likely contain bugs that are fixed upstream in whatwg/html?
- kuschku 10y ago
  WHATWG is a bug. A set of browser vendors just choosing the maximum superset of their implementations for everything. Everything is compatible. That’s the worst possible way to define a standard. A standard is important because it sets limits of what is allowed and what not. Because it is more strict than anything that came before. Because you can actually just implement it, and if something doesn’t work, you can complain to whoever didn’t follow it. The A paper standards say "A ratio of 1 to sqrt(2), A0 is 1m², every smaller standard is exactly half the area of the previous one". Not "Well it’s kinda this or that or that", as WHATWG does. The fight where WHATWG was trying to redefine what URL means, and tried to force cURL and other projects to parse completely retarded patterns as "http:/google.com" (notice the typo) as URL is just another example. As I said in another comment, a standard is supposed to shape the environment it describes, make it simpler. WHATWG standards don’t fulfil that description, they make the web just more complicated than it already is.
  - 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.