HTML 5.1 is a W3C Recommendation
w3.org
w3.org
I'm horribly oversimplifying, but to see the full ugliness, just google 'whatwg w3c'
As for actual technical differences, the vast majority of them are bugs introduced during the copying process, or just places where they haven't caught up to our bug fixes/new features/removals of unimplemented features. (Bug fixes especially roll in quite frequently; see https://github.com/whatwg/html/commits/master .)
There are some differences around conformance requirements, as some of the W3C HTML editors see their fork as a venue for writing a nice official-looking documenton how they think certain HTML elements should be semantically interpreted and used. The big ones I remember are around figcaption, main, hgroup, and others. My favorite is when they made it a high priority to change one of the examples not to use the Flying Spaghetti Monster since it might be controversial. This does not affect implementations of browsers though, just what conformance checkers (validators) like http://checker.html5.org/ tell you about whether your document is conformant.
You can get a full comparison via the third-party tool https://diffofhtmls.herokuapp.com/.
Something like that anyway.
I've set my browser to English as default and use `&hl=de` to tell Google to mix some German hits into the query result.
This is NOT true. W3C vs WHATWG is a "political" issue. Saying either group publishes completely irrelevant documents is misleading.
A set of browser vendors just choosing the maximum superset of their implementations for everything. Everything is compatible.
That’s the worst possible way to define a standard. A standard is important because it sets limits of what is allowed and what not. Because it is more strict than anything that came before. Because you can actually just implement it, and if something doesn’t work, you can complain to whoever didn’t follow it.
The A paper standards say "A ratio of 1 to sqrt(2), A0 is 1m², every smaller standard is exactly half the area of the previous one".
Not "Well it’s kinda this or that or that", as WHATWG does.
The fight where WHATWG was trying to redefine what URL means, and tried to force cURL and other projects to parse completely retarded patterns as "http:/google.com" (notice the typo) as URL is just another example.
As I said in another comment, a standard is supposed to shape the environment it describes, make it simpler. WHATWG standards don’t fulfil that description, they make the web just more complicated than it already is.
Not for the web. You can't break the web, so you can't be stricter that what has already shipped. Sorry.
To your general point; I don't care. I don't want to use tools that are incompatible with what browsers do, and what browsers do is defined by WHATWG HTML, not w3c.
> Not for the web. You can't break the web, so you can't be stricter that what has already shipped. Sorry.
Yes, you can, and yes, you have to.
You’re doing a dangerous tradeoff, sacrificing long-term usability for your marketshare numbers in the next 3 months.
If you want to allow everyone to write a parser able to parse websites, or allow everyone to be able to write websites, then you have to replace and deprecate parts of the web.
In fact, Google does that all the time with Chrome. "HTMLMediaElement can not be controlled on Chrome Mobile, unless your code is running in a click handler, to prevent autoplay".
"GeoLocation API will not be available through HTTP"
"We will not support HTTP sites in the future"
"We will not allow websites to connect to ports that are on our blacklist, including any port below 1024 that’s not 80 or 443, or any port used for IRC or other services"
So, yes, you can be stricter than what has already shipped.
So when can we finally fix all the other issues in the web?
Sounds good in theory. In practice, the opposite is true.
Attempts to define HTML syntax strictly (like DTD-based HTML 4 and earlier, or like XHTML) result in parsers that can't parse websites. But the WHATWG definition of HTML parsing, with its exhaustive and specific attention to handling of error cases, has resulted in HTML parser libraries that are compatible with the actual web. Before that, only browsers could parse real websites as intended and they could only do it through reverse engineering and guesswork.
That’s a good thing.
Because it means websites will be forced to fix their shit, or be broken.
Browsers should start with a strict parsing standard, and color the addressbar in a warning red on every page that doesn’t fulfil it.
After a year or two, remove support for non-strict parsing piece by piece, until a strict situation is the result.
You don’t see WebAssembly parsing everything that’s possible either.
And JavaScript parsers trying to make sense of nonsensical content also haven’t been a thing in years.
In fact, the exact same thing happens with language all the time: A standards body decides to standardize part of the language, and simplify it, and then new grammatical rules are written, and enforced by law in education, and kids learn the new rules that make everything simpler.
A few years later, everyone has adapter – you don’t see anyone using pre-2006 German anymore, either.
If we can do it with fucking language, we also can do it with the web.
I think browser vendors would agree, except that none of the other/normal ways to define a standard are practically available to them.
Browser vendors have settled on this silly sounding approach because web developers have come to rely on literally whatever the browsers actually do.
Many browser bugs can no longer be fixed because too many web developers have come to rely on them. At that point, all you can do is publicly document that this happened and try to move on from there.
You write a standard, and get everyone to agree on it, before implementing it.
But that waterfall concept is considered bad taste in the web world, and so we get websites only running in Chrome because they require a specific non-standard implementation of an experimental feature that will only be standardized in a few months (See: WhatsApp Web when it launched, Google Inbox when it launched).
> Many browser bugs can no longer be fixed because too many web developers have come to rely on them.
As said in a sibling comment, Google Chrome has broken lots of existing websites nonetheless.
So why can’t they do these breaking changes, too?
Typically the result is a terrible feature like AppCache.
Today, I think origin trials are the best alternative to waterfall. https://github.com/jpchase/OriginTrials It allows browsers to experiment with features, even breaking them and deleting them, while working with real web developers and users on actual web sites.
> So why can’t they do these breaking changes, too?
When browser vendors break web sites, their users complain and switch browsers to another vendor that "works."
There is a reason things like IETF require "rough consensus and running code" - because doing the way you suggests sounds really wonderful, but is pretty much is guaranteed 100% to not work in practice. It is hard to find good examples where it led to either good standards, or compatible implementations.
Design by committee is what brought us POSIX, etc. This has worked out .... so well in practice.
When people used to traditional standards complain about WHATWG specs, it's more often for excess precision about edge cases (including error handling on non-conforming content) and resulting lack of implementation freedom. I've never before seen anyone complain about the opposite.
(To be fair, modern W3C specs are much closer to the WHATWG level of precision.)
And for the actually existing web, which is best modeled as infinite monkeys with infinite typewriters, you need this level of exacting precision to achieve actual interoperability.
That’s then writing a dictionary, and it’s fine, but it’s not defining a standard.
As said, the one most important property of a standard is that it simplifies the existing situation, and is stricter than what came before.
The W3C once produced standards, now not anymore. The WHATWG never produced standards.
I mean, we can fucking standardize languages and adapt the way people spell something or the way they use grammatical constructs by law within of only a few years.
If we can do it with natural language, doing it with the web is completely doable. Because languages ARE infinite monkeys with infinite typewriters.
People with your attitude are a big part of why the W3C HTML Working Group failed. It's easy to expound on what Real True Standards should be when you have no real skin in the game. Those with a real stake in the result care about what actually works instead, and have no time for this kind of philosophizing.
The creation of the WHATWG was obviously a bad day for web standards, but at this point one has to be pragmatic. The existence of the W3C spec only adds confusion, and little to no value.
But new features like the fetch standard get written before implementations (with vendors and other stakeholders involved in the process), or simultaneously with implementations.
It must be admitted that many aspects of HTML appear at first glance to be nonsensical and inconsistent.
HTML, its supporting DOM APIs, as well as many of its supporting technologies, have been developed over a period of several decades by a wide array of people with different priorities who, in many cases, did not know of each other’s existence.
Features have thus arisen from many sources, and have not always been designed in especially consistent ways. Furthermore, because of the unique characteristics of the Web, implementation bugs have often become de-facto, and now de-jure, standards, as content is often unintentionally written in ways that rely on them before they can be fixed.
That kind of says it all when it comes to web standards!
Read the history of XHR and you'll get a fascinating look at how clever teams can slip real innovation into products just by tickling the right business folks' ears.
http://www.alexhopmann.com/story-of-xmlhttp/
> Which is the real explanation of where the name XMLHTTP comes from- the thing is mostly about HTTP and doesn’t have any specific tie to XML other than that was the easiest excuse for shipping it so I needed to cram XML into the name (plus- XML was the hot technology at the time and it seemed like some good marketing for the component).
Not sure if this is serious. https://www.w3.org/TR/2016/REC-html51-20161101/introduction....
That is actually a pretty accurate representation of how reading entire specs with intent to implement goes. I've done this twice with the xhr and file specs :) Maybe not the reading backwards part.
[1]: https://www.w3.org/TR/2016/REC-html51-20161101/changes.html#...
Then I would probably prefer to use <blink> and <marquee>.
[1] https://w3c.github.io/test-results/html51/implementation-rep...
What I've found interesting is that markup for insertions and deletions in this file is ("non-semantic") `<span class="delete">..</span><span class="insert">..</span>`, instead of presumably more semantically appropriate `<del>..</del><ins>..</ins>` [1].
[0] https://github.com/w3c/html/blob/master/diff/html5to51diff.h... [1] https://www.w3.org/TR/2016/REC-html51-20161101/edits.html#el...
It's much less a buzzword than it is a set of specs which let HTML documents convey more semantic information, which in turns has implications for e.g. accessibility, among others.
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).
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.
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!!)