For those who have not been paying attention for a decade, what's the relationship between this revision and WHATWG?
It's absolutely a fiction, but at the same time, this at least attempts to be a standard.
The WHATWG version seems more like a reflection of "oh by the way that's the rules our browsers are following this month. Your's truly, the browser vendors."
So far we've done our best to keep a really readable, tidy Git commit log, which should help with understanding changes: https://github.com/whatwg/html/commits/master
If you omit the "Editorial:" or "Meta:" commits, I think it's actually at a similar level of detail as the W3C fork's changes log. (Not completely; scrolling through I do see a number of commits that wouldn't be relevant.) But the W3C fork has only managed to copy-and-paste a small subset of our changes, so indeed, the changes log for the last year of work at the WHATWG will be somewhat daunting compared to the small subset they managed to copy over.
There may be room for someone to compile a higher-level "this week/month/year in the HTML Standard" or similar; before I started working in the WHATWG, that actually used to exist: https://blog.whatwg.org/category/weekly-review (also in very amusing YouTube form: https://www.youtube.com/watch?v=1Bg5BPnmj68). So far we haven't had the bandwidth to restart that, but if you or someone else wants to contribute that sort of thing to the blog or elsewhere, I'd love to help you get started.
I don't think the commit history works. It doesn't give you any indication about which changes are relevant or irrelevant and it doesn't tell anything about the larger efforts taking place.
Actually, I don't think it would even make sense to create an equivalent of the W3C diff, because there are no versions or other structures to organize the changes around - there is just a constant stream of changes. (Which is kind of the point of the living standard concept after all)
Personally I'd tend toward weekly or monthly, although I admit that yearly is more likely to generate HackerNews posts ;)
EDIT: Apparently even that description was too charitable towards the W3C (see gsnedders comments).
But is that actually an improvement over the previous situation? (Serious question.)
No, it means we have two increasingly different documents purportedly defining the same things, and when they do copy patches over they've failed to also copy over other dependent patches too on a number of occasions leaving their spec as defined unimplementable.
Practically speaking, the Web is a consortium of corporate foghorns that also happen to collectively be the majority ad-hoc directors of new media (translation: agendas with finance). Cable and daytime TV was the old media, which of course still exists, and social media has become a juggernaut majority of its own beside that.
So, you'd think the actual grassroots on-the-ground parts of a project that is ostensibly defined to be open and free, would actually be made of extremely smart people with straightforward management and as little bureaucracy as possible. Because, you know, the part where everything hits the ground needs to be well-oiled, have no chinks in the armor, and provide a secure foundation of independence.
And yet we have... chaos, infighting, politics and wars over (literally) nothing. And while all that's happening, corporations are progressively nibbling away at the capabilities we have today (to set up websites, to communicate freely) that we take for granted. One day we'll wake up checkmated by some incredibly well-engineered chess move...
Sighs
If the net neutrality thing is repealed, I will be exactly 0% surprised. It'll just be another EME, really.
It shouldn't be their job to decide how browsers should work, that's the browser makers' decision. (Which happens to be large corporations, for the most part.)
Nevermind the fact that the landscape has changed to the point where that isn't a realistic outcome anymore.
Nevermind the fact that in the instance I'm describing (which was something like WebASM or WebSockets.. it was WebSomething and I can't recall the name), they had submitted their proposals to the standardization groups, with no change on the volume of the noises.
I wish people would decide whether they want browser makers trying New Stuff or they want New Stuff coming from standards bodies only. There are upsides and downsides to either way, but I really don't beleive that BMing browser makers whenever they try New Stuff is even sort of constructive.
This seems to make the most sense because the browser is the end product by which people consume their internet.
It seems to me, they have been and always will be years ahead of the governing bodies that make these part of their "standards" decisions. By the time something finally makes into the spec, we're already onto a dozen new things the browsers are capable of and implementing.
At this point it just feels like the spec is an afterthought, not necessarily keeping up with how fast the industry is changing.
“HTML Living Standard — Last Updated 13 December 2017”
https://html.spec.whatwg.org/multipage/
I've been telling students that the W3C develops and maintains the HTML spec. Looks like I'm dead wrong. Oops.
tl;dr: Ignore w3c's HTML "standards" as they are (often poor) copies of WHATWG's standards.
I my opinion one cannot call something a "standard" that changes every few days.
EDIT: In this sense W3C's HTML 5.x can be considered a rather badly authored (cf. other comments here) standard, while what the WHATWG releases is not something that even measures up to a standard, but it is the daily version of how HTML is supposed to be today.
What parts of the standard are stable?
The whole standard is more or less stable. There are some parts of it that describe new technologies that have not yet been implemented everywhere, but at this point those additions are only added after the design itself is pretty stable. Such additions must also have the support of two or more implementers, per our working mode[1].
Why are there no stable snapshots, or versions, of the standard?
In practice, implementations all follow the latest standard anyway, not so-called "finished" snapshots. The problem with following a snapshot is that you end up following something that is known to be wrong. That's obviously not the way to get interoperability!
This has in fact been a real problem at the W3C, where mistakes are found and fixed in the editors' drafts of specifications, but implementers who aren't fully engaged in the process go and implement obsolete snapshots instead, including those bugs. This has resulted in serious differences between browsers.
So, WHATWG is in constant flux, and W3C has about as much authority as I do. _Thankfully_ in practice WHATWG is "stable enough," but just saying that's what "we" consider a good enough standard for something used in creating all sorts of UIs, from trivial to vitally important, is indicative of a bigger problem.
There exist lots of standards that hardly anybody cares about. So this is clearly not true.
Just because it changes often doesn't mean things are sloppily accepted, or that experimental ideas are added and later removed.
Indeed, if you want to build something for the web, reading an outdated document that contains bugs browsers have already fixed is not a good idea.
When you do a project contract, you surely want to define the exact standard with respect to which the application is to be developed against, so that one can decide whether the reason for something looking wrong is a browser bug (I can work around it - but it will cost extra money) or indeed a bug in my code that the customer found (i.e. I have to work extra hours for no money because I did bad work).
To be able to decide such questions is a central purpose of existence for standards.
I already argued that there is no WHATWG standard, but only a document that changes every few days. Even without this nitpicking: Which of these thousands of versions is the one on which the browser implementation is based on?
Do you really want to make a requirements document that describes something different at the day you sign it and at the day you deliver?
Wake up.
You can't compare it to browsing on Amazon, because functionality doesn't just go missing and literally break buying things; functionality doesn't just suddenly get added and people rely on the exact font size and copy of a particular header in the men's clothing department to be precisely 2em and "Men’s Clothing," and now that it's changed to 1.5em and "Men's Winter Fashion" a third-party app can't render the header in an appropriate width size nor find the clothes to begin with.
Counterexample: About three months ago I asked on HN why on modern browsers some subtests of Acid3 fail:
> https://news.ycombinator.com/item?id=15256890
I actually got some pretty smart answers, for example:
> https://news.ycombinator.com/item?id=15259428
To quote it for convenience:
"Two changes lead to three failures in Chrome.
The first change is described in the 'note' at https://drafts.csswg.org/selectors-4/#child-index
Chrome is failing a test because the root node claims to be a 'first-child'.
The root node is the first sibling, but since it doesn't have a parent, the selectors 3 spec didn't include it.
The selectors 4 draft does away with the requirement that a 'first-child' have a parent, and chrome's behaviour matches.
The second is discussed here https://github.com/whatwg/dom/issues/319
Roughly, when interpreting qualified names, Chrome is throwing InvalidCharacterErrors when the acid test wants it to throw NamespaceErrors, in situations where you really have both. This leads to two tests failing."
So decide for yourself whether the WHATWG "standard" did breaking changes in the past or not.
The advantage to following the WHATWG specs is that it reflects how browsers work today, not how they worked a few years ago.
A standard is something like ISO EN DIN A4. It is defined in cooperation with every stakeholder involved, it is specced, it is tested, and a stable definition is created. Everyone builds against this definition, and it works fine. The standard deprecates everything that existed before, and replaces it.
That is a standard. It’s authoritative, basically immutable, and it is prescriptive.
WHATWG "standards" come after the fact, only consider whatever browsers implement, refuse to ever deprecate anything (unless browsers have already deprecated it), and almost always just are "whatever Google Chrome does". That’s a disgusting abuse of the word standard.
WHATWG "standards" are the equivalent of Microsoft Office Open XML, a standards body just taking an existing implementation, defining whatever it does as standard, and doing it so incomplete that the result is useless.
Yes, WHATWG and W3C are doing the best they can do in the current climate (where Google can roll out QUIC and SPDY before even any standard is defined across websites accounting for 6% of global traffic, 65%+ of web browsers, and 85%+ of mobile phones), but this is just misleading. It helps no one to pretend to do standardization work when you don’t actually have any power to decide anything – neither WHATWG nor W3C can actually force, or even ask, Google to change SPDY or QUIC. They’re papertigers.
The W3C is for web authors. It presents a more stable recommendation and provides advice (based on research) for authors.
> The W3C is for web authors. It presents a more stable recommendation and provides advice (based on research) for authors.
Web authors usually use MDN instead, because it serves that purpose in a much better way. (Note that despite the name MDN is not Mozilla specific but a cross-browser resource, and that Microsoft and Google recently joined MDN.)
> The WHATWG is for browser vendors. It's in a constant state of flux as new changes get proposed and those proposals get changed through implementation.
The W3C recommendation is no different in that regard, they also describe stuff that's not fully implemented in all browsers yet. But the WHATWG version is more up to date, so you'll notice much earlier that the new feature you want to depend on will be abandoned or changed.
Note for a W3C document to go to Recommendation there must be two interoperable implementations. Of course, that doesn't mean any browser has implemented any of it, just that someone has implemented each part of it.
Conversely the W3C specifications are fixed to versions and are occasionally patched with updates. The W3C process is incredibly slow and conservative, which frustrates developers on the bleeding edge. Due to the slow process, thoroughness of that process, and formal versioning most software vendors prefer to implement against the W3C publications as more stable or reliable.
W3C is supposed to be properly supported everywhere.