>In 2011, however, the groups came to the conclusion that they had different goals: the W3C wanted to publish a "finished" version of "HTML5", while the WHATWG wanted to continue working on a Living Standard for HTML, continuously maintaining the specification rather than freezing it in a state with known problems, and adding new features as needed to evolve the platform.
>Since then, the WHATWG has been working on this specification (amongst others), and the W3C has been copying fixes made by the WHATWG into their fork of the document (which also has other changes).
A proper standards group could have a new HTML x.Y version come out every 6-12 months. Now, who knows what is valid HTML? I don't know where to go to know when or if a <date> or <number> or <em> or <marquee> tag is valid, or what browser supports it.
What WHATWG HTML is valid changes, say, every weak. If you want something official that does not change what valid HTML is every now and then better go to the W3C. ;-)
* the W3C wanted to publish a "finished" version of "HTML5"
Putting "finsished" into quotes is a hint of sarcasm of the WHATWG side.
* continuously maintaining the specification
Fixing known bugs is also a kind of continuous maintaining of a standard (this is what the W3C and other standard bodies do). That the WHATWG writers put this into contrast of the approach of the W3C is smugness again.
* rather than freezing it in a state with known problems
Fixing bugs and publishing errata is common for standards. The wording implies that this is something the W3C does not do.
* and adding new features as needed to evolve the platform
Having a stable standard which one can refer to (say in project contracts or for tooling) is also an important feature. The WHATWG connives over this and only considers the things that they do as features.
* Since then, the WHATWG has been working on this specification (amongst others), and the W3C has been copying fixes made by the WHATWG into their fork of the document
A very smug way to say "WHATWG does all the work and W3C is a copycat". Though the facts might be true, there are more humble ways to express that.
* (which also has other changes).
OK, what the W3C does is not really important - we can skip over these changes as they are not important (only the WHATWG version is).
> Fixing known bugs is also a kind of continuous maintaining of a standard (this is what the W3C and other standard bodies do).
And:
> Fixing bugs and publishing errata is common for standards. The wording implies that this is something the W3C does not do.
There are countless W3C specs that don't have errata kept up-to-date, and, hell, the 5.1 errata is just <https://github.com/w3c/html/issues> (if they fix a bug in 5.2 drafts, will they keep the issue open so it continues to appear on that (paginated) list of issues or not? because both options seem terrible!). Similarly, the W3C almost never issues revised recommendations to incorporate errata, which means even for specs where there have been no errata for years you have to cross-reference two documents.
Another example is CSS 2.1, which doesn't have errata published any more: they're just fixed in the editor's draft of 2.2, and left to linger in the 2.1 Recommendation and errata.
For plenty of W3C specs the only "errata" is an editor's draft of the next revision.
Oh, yes, there are absolutely counter-examples. It's essentially down to each WG whether they issue errata or revised recommendations, and when plenty of (admittedly more obscure) WGs have their charter allowed to expire when all of their deliverables have become recommendations there's at times nobody to maintain the document per the W3C process.
An aside:
XML 1.0 Fifth Edition is actually a weird case: there are documents that are well-formed XML according to the Fifth Edition and not well-formed according to the Fourth Edition, because the characters allowed in places like tag names went from being based on Unicode 2.0 to Unicode 5.0-or-any-later-version (which was originally the difference between XML 1.0 and XML 1.1, except 1.1 was originally 3.0-or-any-later-version); as such, two XML 1.0 implementations are no longer guaranteed to consider the same set of documents well-formed, as it depends on the Unicode version each uses. As a result, plenty of implementations of XML 1.0 have no plan on changing away from their Forth Edition implementations.
What's up with the W3C hate here around? As far as I can see all they're trying to do is to publish a snapshot of WHATWG's work, which WHATWG refuses to do.
There are those of us who need to develop against a stable feature set. Browser developers aren't the only ones interested in HTML, it's one of the most used vocabulary/API of all times. Is it unreasonable to expect some results after more than 10 years of work.
I think some WHATWG members make themselves a bad name by ridiculing W3C publicly; WHATWG do great work, why do they find it necessary to troll W3C?
I have a feeling it is it because they think they "own" HTML or something. In that case, they should be reminded of the fact that neither WHATWG nor W3C are "standards bodies" vs. IETF and ISO/IEC, say.
Because it's not just a snapshot—it has a growing diff to the WHATWG spec, and when they do copy over commits they sometimes do so incompletely. (An example of this is the HTML 5.1 definition of document.domain: if you try and set it to any host except for the current one it throws SecurityError; this came about as a result of bogusly applying patch from WHATWG spec.)
As far as I'm aware, most of the annoyance of the W3C fork is the fact that there's good people spending a lot of time on it (instead of, e.g., working on specifying parts of the Web platform that every modern site relies on that are essentially undefined, like the CSSOM), and the fact that it isn't just a snapshot and that it therefore causes confusion with two different, at times contradictory documents.
Probably because the W3C literally copy/pastes other's work and claims it for their own. Look at this blog post, which doesn't credit WHATWG at all for doing the actual work of speccing HTML.
"Probably because the W3C literally copy/pastes other's work and claims it for their own. Look at this blog post, which doesn't credit WHATWG at all for doing the actual work of speccing HTML."
I don't know or care, I didn't claim that W3C is breaking a license, just that they are taking other people's work and claiming it as their own. That you can't see the difference between these things is not anything I can help you with.
"I didn't claim that W3C is breaking a license, just that they are taking other people's work and claiming it as their own."
The only reason I ask? If there's a license you can force the W3C to display it. I can see what you're getting at, and if the W3C as an organisation is stupid enough to make claims on ideas from WHATWG they should be reminded and forced to acknowledge this through law. One way to do this is enforcement by license.
It's absurd to think that W3C is claiming WHATWG's work as their own. W3C specs are read by relatively few people who generally know about the text provenance and its relationship with WHATWG specs.
> There are those of us who need to develop against a stable feature set.
Can you explain what you mean here more? The HTML standard doesn't break compatibility, if that's what you mean, because of course that's not possible. So I suspect you mean something else; can you explain?
Sure. For example, WHATWG has recently removed scoped styles from HTML (don't know if this change made it into W3C's HTML 5.1), and probably for a good reason. Now you could say scoped styles were never in a published "standard", and rightly so; but that's kindof the problem, because WHATWG never publishes or commits to anything. Say you have contractual obligations to deliver HTML; had you used scoped styles, you're now in for some extra work to replace it with something else.
I can't remember off-hand, but scoped styles shouldn't have made it into 5.0's Recommendation (one of the requirements for CR to PR advancement is showing each feature has implementation experience), though if it did it wouldn't be the only one that made it through into HTML 5.0 despite the W3C process.
As for the WHATWG, I don't believe that any feature without implementer support has landed in the WHATWG HTML spec in several years now, and I think there's a clear intention to keep it that way, so there shouldn't be featured that never get implemented in the spec.
This was just an example, please don't take it as criticism.
The point, though, stands, and is illustrated by the fact that I can't even use a permalink to a version of the WHATWG HTML spec that still has scoped styles defined (at best, you can point to a ancient bikeshed or anolis commit).
I, for one, find value in W3C's HTML 5.1 publication. I couldn't have justified the effort to do my analysis/review of HTML 5 at http://sgmljs.net/docs/html5.html based on a volatile and ever-changing standard.
Mind you, the analysis is purely from a markup/formal language, not webdev PoV.
HTML is nice because you can come up with your own elements and attributes. I for example use the abstract element a lot. And there are unofficial elements and attributes that help screen readers.
What is considered as good design depends a lot on the zeitgeist and culture. For example in Asia (e.g. China, but also Japan) there is a rather different taste what is considered as a well-designed website:
I think you're mistaken. The site tries to be modern by including 'material design' elements. I'm not gonna lie, I think it's extremely ugly and cluttered, but functional.
https://news.ycombinator.com/item?id=12848419