This is a completely irrelevant document. Browser makers follow standards written by the WHATWG (Web Hypertext Application Technology Working Group), not the W3C.
I'm horribly oversimplifying, but to see the full ugliness, just google 'whatwg w3c'
It goes both ways. Unspecced behavior might get specced by the whatwg. Of it turns out that whatwg's spec doesn't match most browsers, that is a spec bug. If it matches some browsers but not others it usually gets discussed and consensus is reached. Sometimes the spec does one thing, some browsers do a different thing, and some browsers do yet another thing. More discussion.
But new features like the fetch standard get written before implementations (with vendors and other stakeholders involved in the process), or simultaneously with implementations.
As for actual technical differences, the vast majority of them are bugs introduced during the copying process, or just places where they haven't caught up to our bug fixes/new features/removals of unimplemented features. (Bug fixes especially roll in quite frequently; see https://github.com/whatwg/html/commits/master .)
There are some differences around conformance requirements, as some of the W3C HTML editors see their fork as a venue for writing a nice official-looking documenton how they think certain HTML elements should be semantically interpreted and used. The big ones I remember are around figcaption, main, hgroup, and others. My favorite is when they made it a high priority to change one of the examples not to use the Flying Spaghetti Monster since it might be controversial. This does not affect implementations of browsers though, just what conformance checkers (validators) like http://checker.html5.org/ tell you about whether your document is conformant.
Basically W3C tries to define versioned HTML specifications, but they basically follow what browsers actually implement and are always out of date. WHATWG maintain a "living standard" and is really what browser vendors actually work with because it doesn't attempt the slow and futile task of defining a 'stable' versioned spec.
For me, this redirects to the German version (I'm in Germany on a device with a German locale). I'd really love to have a way to tell Google to only show English-language hits.
The W3C document may be relevant to some small minority but the majority of people developing using HTML5 are targeting a set of clients that mostly or entirely follow the WHATWG's version in their actual implementations, and this is what defines relevance.
The creation of the WHATWG was obviously a bad day for web standards, but at this point one has to be pragmatic. The existence of the W3C spec only adds confusion, and little to no value.
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.
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.
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.
> That’s the worst possible way to define a standard.
I think browser vendors would agree, except that none of the other/normal ways to define a standard are practically available to them.
Browser vendors have settled on this silly sounding approach because web developers have come to rely on literally whatever the browsers actually do.
Many browser bugs can no longer be fixed because too many web developers have come to rely on them. At that point, all you can do is publicly document that this happened and try to move on from there.
You write a standard, and get everyone to agree on it, before implementing it.
But that waterfall concept is considered bad taste in the web world, and so we get websites only running in Chrome because they require a specific non-standard implementation of an experimental feature that will only be standardized in a few months (See: WhatsApp Web when it launched, Google Inbox when it launched).
> Many browser bugs can no longer be fixed because too many web developers have come to rely on them.
As said in a sibling comment, Google Chrome has broken lots of existing websites nonetheless.
"You write a standard, and get everyone to agree on it, before implementing it."
There is a reason things like IETF require "rough consensus and running code" - because doing the way you suggests sounds really wonderful, but is pretty much is guaranteed 100% to not work in practice.
It is hard to find good examples where it led to either good standards, or compatible implementations.
Design by committee is what brought us POSIX, etc.
This has worked out .... so well in practice.
> waterfall concept is considered bad taste in the web world
Typically the result is a terrible feature like AppCache.
Today, I think origin trials are the best alternative to waterfall. https://github.com/jpchase/OriginTrials It allows browsers to experiment with features, even breaking them and deleting them, while working with real web developers and users on actual web sites.
> So why can’t they do these breaking changes, too?
When browser vendors break web sites, their users complain and switch browsers to another vendor that "works."
WHATWG specs aren't "it's kind of this or that". They're more like "it's exactly X, in 20 detailed steps of excruciating detail, and if X is a legacy feature we're sorry that it's kind of weird.
When people used to traditional standards complain about WHATWG specs, it's more often for excess precision about edge cases (including error handling on non-conforming content) and resulting lack of implementation freedom. I've never before seen anyone complain about the opposite.
(To be fair, modern W3C specs are much closer to the WHATWG level of precision.)
And for the actually existing web, which is best modeled as infinite monkeys with infinite typewriters, you need this level of exacting precision to achieve actual interoperability.
> you need this level of exacting precision to achieve actual interoperability.
That’s then writing a dictionary, and it’s fine, but it’s not defining a standard.
As said, the one most important property of a standard is that it simplifies the existing situation, and is stricter than what came before.
The W3C once produced standards, now not anymore. The WHATWG never produced standards.
I mean, we can fucking standardize languages and adapt the way people spell something or the way they use grammatical constructs by law within of only a few years.
If we can do it with natural language, doing it with the web is completely doable. Because languages ARE infinite monkeys with infinite typewriters.
WHATWG HTML and W3C HTML both define a valid syntax for content, as well as parsing rules that cover everything, even error cases. Postel's Law states: "Be conservative in what you do, be liberal in what you accept from others.". Modern HTML standards codify this rule in a serious and detailed way. I think Jon Postel knows more about real standards than you do.
People with your attitude are a big part of why the W3C HTML Working Group failed. It's easy to expound on what Real True Standards should be when you have no real skin in the game. Those with a real stake in the result care about what actually works instead, and have no time for this kind of philosophizing.
> 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.
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?
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.
> 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.
> 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.
But the W3C spec is essentially a snapshot of the WHATWG, so I don't see how this is relevant in a discussion of whether a tool should use one or the other spec.
I'm horribly oversimplifying, but to see the full ugliness, just google 'whatwg w3c'