Full story here: https://www.reddit.com/r/javascript/comments/5swe9b/what_is_...
tl;dr: Ignore w3c's HTML "standards" as they are (often poor) copies of WHATWG's standards.
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.