TL;DR The above document is irrelevant and should be ignored. Popular browsers' implementations define the HTML5 that most devs will want to target, and those browser vendors are members of the competing WHATWG body. They will largely ignore the W3C copy.
WHATWG HTML (formerly HTML5) is "rolling release"; the only version numbers are the "Last Modified" date at the top of the document. Meanwhile, W3C HTML5 has defined releases that are thoroughly scrutinized, reviewed, and debated in endless committee meetings.
One of these models is good for rapid-release and fast iteration. The other isn't.
Finally, W3C members are large companies, not individuals (with a few notable exceptions, like Aaron Swartz). WHATWG members are mostly individuals, many of whom are ordinary web developers who don't work on browser implementations. This difference is largely the raison d'être of WHATWG; it was the perception of many that W3C standards were diverging from what actual web developers wanted.
> Meanwhile, W3C HTML5 has defined releases that are thoroughly scrutinized, reviewed, and debated in endless committee meetings.
While this was true in the past, these days it's not really the case. They mostly just copy and paste our work without scrutinizing it, and usually without understanding it (as can be seen by the bugs they introduce during the copy-and-paste process). There aren't really any technical deliberations or committee meetings, and they don't follow a well-defined process; the most recent fork (from which HTML 5.1 is based) was actually done without the knowledge of the membership, and broke several aspects of W3C process while doing so.
Why do they do this? Well, it seems to be largely an issue of institutional face-saving. See e.g. https://github.com/w3c/charter-html/issues/14#issuecomment-1...: "When the HTML WG co-chairs and Team presented our proposed After HTML5 plan to the W3C Advisory Board earlier this year, we received a clear message that it was not appropriate to delegate or assign the maintenance of a W3C Recommendation outside the organization." In other words, since they started copying and pasting back in the day with HTML 5.0, they can't stop now.
Meanwhile there's actually a lot of interesting deliberation between web developers and browser vendors over in the WHATWG HTML Standard's bug tracker. https://github.com/whatwg/html/pulse might give a reasonable overview. Compare to https://github.com/w3c/html/pulse.
Some relevant corroborating links:
- https://annevankesteren.nl/2016/01/film-at-11 when this all started
- https://wiki.whatwg.org/wiki/Fork_tracking monitoring the ongoing copy-and-paste-induced confusion
- https://github.com/w3c/html/issues/364 wherein they monitor our tree for things to copy and paste over
- https://github.com/w3c/html/commit/19fcaf241f4417b2078bc26bf... example commit of them copying and pasting our work en masse (Spot the bugs introduced! It's a fun game!)
Get rid of all the backwards compatibility shit, and actually create strict, and simple standards, with no unexpected behaviour, that only parse valid documents, and where anyone can write an implementation?
Because that’s the definition of a standard.
That’s what a standard is supposed to be.
Standards, from paper standards to screws to fucking cucumber regulations are supposed to be more strict than what came before them, so anyone can easily accept only one type, and know it will work.
The WHATWG "standards" don’t fulfil the definition of standard in the least.
They are a strict superset of everything all implementers accept, making it a larger and more complicated mess with every single iteration.
So when will the WHATWG, as you say it’s now the legitimate standards body, do what it, as standards body is supposed to do, and deprecate currently used behaviour to replace it with stricter, simpler, standard behaviour?
Yes, that will break the web, but yes, it will also improve it.
If you just document what already exists for the benefit of existing implementors, great, you just got Microsoft Office Open XML.
That, and nothing more, is everything that can result from such a mindset.
There is nothing you can do to change this.
Your comments are getting downvoted to hell and back because you either don't understand or are unwilling to accept this constraint.
What would you rather happen with mangled input like opening tags with no ending tag? Should the browser always try a best effort and never die with errors? Perhaps we can afford to break some things even though we can't afford a clean break?
I think you'd agree that the perfect is the enemy of the good. I'd argue that perfect backward compatibility is the enemy of good backward compatibility as well. Thoughts?
I'm unwilling to accept this is a hard constraint. It can't be that a later version should accept all inputs accepted by an earlier version. We should carve out exceptions based on what's actively used and inform the developer that what they're using is bad code. Eventually, some day if it becomes rare, we can discontinue support.
As for individual members, the differences in contribution process between the organisations renders this largely irrelevant. WHATWG membership affords the right to submit proposals and ideas but not to participate in decision-making, which is up to (usually sole) editors, who represent large companies (much larger than most W3C members).
Specific example: RDFa vs microdata. One was well understood, the other made up on the spot. One played well with a huge amount of preceding standards, the other... meh.
While bleeding edge fashion brings great and new things to a culture, it also risks local maxima - a point where you cannot evolve further without negatives.
Examples: Blockbuster vs netflix, Rails new vs computer science; and dinosaurs vs mammals (you cant eat us all despite jurrassic park, you giant chickens!!)
The HTML WG was merged into the Web Apps WG in 2015 to form the Web Platform WG; previously, the HTML WG was rechartered in 2007 to work on HTML5 (the previous WG of the same name had been working on XHTML2), with a novel experiment within the W3C, heavily influenced by the WHATWG: allowing anyone who agreed to the IP policy (essentially, an irrevocable patent grant unless you explicitly mentioned a patent you held within a certain period) to become an Invited Expert (under the somewhat nonsensical term "Public Invited Expert").
This WG fairly quickly became relatively unworkable (people refusing to listen to other's arguments, being completely unable to come to consensus on a number of issues, a habit of subgroups presenting things at fait accompli and then failing to accept there might be any flaws in their work, an ever growing number of ad hominem attacks, and general interpersonal nastiness). Eventually, all the browser vendors essentially went back to doing all the work in the WHATWG leaving those not directly involved with web browsers to work on the W3C spec. Many of the historic arguments were clashes between what browsers saw as workable v. theoretical purity (and yes, this is reminiscent of HTML5 v. XHTML2, again, and that's with web developers within the WG), and with the browser vendors gone there's little opposition to most of what is proposed, and hence there's relatively little debate about much of what's done. As more time passes, there's ever less opposition. There's far more debate over features within the WHATWG, but also far more civility.
This all said, it's been possible to contribute to many W3C standards while not being a W3C Member or WG member for years, by simply contributing to the mailing list or more recently GitHub (this is typically only complicated for employees of W3C Members whom aren't permitted to join the WG by their employer). If web developers want to get involved in groups at the W3C whether that's HTML, Web Components, or CSS, all of which are primarily worked on on GitHub nowadays, I encourage you to comment on issues, or file new ones! There have definitely been people who have become Invited Experts through such actions, and some who have been hired to work on standards as a result, and on a personal note I can attest that the CSS WG is a nice, functional group, full of nice people! (I've been a member on-and-off since ~2010, originally as an Opera Software rep, nowadays as an Invited Expert, with a period of being neither inbetween.)
At the same time, much of the power of the W3C is held by the Advisory Committee (and, mostly theoretically, the Director, TimBL) and that's formed solely of W3C Members (people who are Invited Experts have no say here!), with votes needed both to start working on a new area (e.g., restarting work on HTML) and advancing a spec along the Recommendation-track. It is there the Members have power, and all are considered equal. There are plenty of cases the first time a Member really gives any statement about a spec is just before it gets published as a Recommendation, and really at that point it's too late unless the objections are really fundemental.