The W3C version is a sporadically updated, bad-faith fork of the WHATWG version, created to maintain the fiction that it "owns" HTML, which it deems necessary to maintain the organisation's standing (and funding) in the eyes of other organisations and governments.
And yet, we don't get things like that changes page from the WHATWG version. (Unless you want to dig through the whole commit history)
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."
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.
But this is kind of my point: As of now, this doesn't exist.
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)
The W3C fork's versions are arbitrary too though (yearly). You could organize a yearly update on what's new in the HTML Standard if you thought that would be valuable to people. It wouldn't change the fact that browsers release new features based on the ever-changing standard every six weeks. But it sounds like at least some people would find it useful.
Personally I'd tend toward weekly or monthly, although I admit that yearly is more likely to generate HackerNews posts ;)
I think of it like WHATWG is the git master branch of the "html" standard, and W3C regularly packages a modified (changing things they disagree with) version of it and "release" it with a version number (HTML 5.x), going through alpha, beta, etc. By the time it's finalized, it's out of date.
I hope this doesn't sound too snarky, but as far as I know, the WHATWG standard is live, consistent and always up to date (including corrections), while the W3C recommendations are outdated snapshots of the WHATWG standard, which are labeled by arbitrary version numbers instead of the snapshot timestamp, for whatever reason.
EDIT: Apparently even that description was too charitable towards the W3C (see gsnedders comments).
They stopped really doing snapshots of the WHATWG standard a while ago when they moved their authoring toolchain away from what the WHATWG document uses, and now just occasionally selectively copy over patches (sometimes incompletely) and make their own changes.
> 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.
I know the current manglement isn't explicitly malicious, but this is an atrocious state of affairs.
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.
At this point both W3C and WHATWG are not where innovation on the web is (or should be) happening. It's up to the individual browser makers to innovate. W3C and WHATWG's job should be to document any consensus among browser makers.
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.)
That just gets the browser makers castigated by the tech community. Every time, say.. Google, intents something new, the entirely predictable incoherent screaming starts about how it's another Microsoft IE/ActiveX.
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.
> It's up to the individual browser makers to innovate.
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.
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.
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.
It's not enough to be stable to be a standard, you also need authority that enforces it. Either because people "respect you" (whatever that means), or because there's a central authority forcing them to implement the standard, people actually implement it. If they don't, then it's not much of a standard.
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.
> Just because something changes often doesn't mean it is unstable.
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.
> When I do a project I want to be able to code against the standards from which browsers were developed; that is the WHATWG standard.
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?
This one: https://html.spec.whatwg.org/multipage/ . Contrary to some people's perception here, everything that goes into this is implemented by at least 2 browsers.
Sorry, but you can't print that page and use that forever. I understand that you wish that you could, but you can't. I live in the real world, so rather than reading a snapshot and hoping it stays that way forever, I just read the up-to-date version since that's what is implemented by browsers, not the PDF I saved 3 months ago.
Given that the browsers with respect to which you implement the code change under your feet every 6 weeks, I think it's better the standard keeps pace with them than having it give a misleading impression of what you're developing against.
I hope we can agree HTML is used for text content first and foremost. A format that changes all the time at the whim of an ad company is basically useless for long-term preservation of legal documents, or documents in education, etc. Do you think having the latest web app fad is more important? Especially when the format has been around for 25 years now. "Innovation" on the Web is only happening so that Google can keep an edge in search tech, and for similar reasons.
This just speaks from lack of experience: that's exactly what it means in the world of software. Do you not understand what specification means? "Specific" is even in the word.
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.
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 csswg is a W3C working group. It's true that there are sometimes breaking changes if usage is low enough. This is true of the W3C specs as much as it is of the WHATWG specs.
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 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 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.
> The W3C recommendation is no different in that regard, they also describe stuff that's not fully implemented in all browsers yet.
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.
The WHATWG specs contain a lot of innovation, but change more rapidly. In many cases WHATWG specs are living documents that gradually evolve and adapt to changes in real time.
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.
