HTML 5.1 is a W3C Recommendation(w3.org)
w3.org
HTML 5.1 is a W3C Recommendation
https://www.w3.org/blog/news/archives/5932
71 comments
Rather, the WHATWG writes standards that comply with what browser makers do.
It goes both ways. Unspecced behavior might get specced by the whatwg. Of it turns out that whatwg's spec doesn't match most browsers, that is a spec bug. If it matches some browsers but not others it usually gets discussed and consensus is reached. Sometimes the spec does one thing, some browsers do a different thing, and some browsers do yet another thing. More discussion.
But new features like the fetch standard get written before implementations (with vendors and other stakeholders involved in the process), or simultaneously with implementations.
But new features like the fetch standard get written before implementations (with vendors and other stakeholders involved in the process), or simultaneously with implementations.
Any specific article explaining what the difference between the two are ? My google being in french, I don't get much results...
I tried to leave some details here on the situation downthread: https://news.ycombinator.com/item?id=12849375
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/.
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/.
Basically W3C tries to define versioned HTML specifications, but they basically follow what browsers actually implement and are always out of date. WHATWG maintain a "living standard" and is really what browser vendors actually work with because it doesn't attempt the slow and futile task of defining a 'stable' versioned spec.
Something like that anyway.
Something like that anyway.
Further down is a comment by LukeShu that explains the difference a bit:
https://news.ycombinator.com/item?id=12849105
https://news.ycombinator.com/item?id=12849105
You already got many relevant answers but just in case you need it again, https://www.google.com/ncr redirects to the international version.
For me, this redirects to the German version (I'm in Germany on a device with a German locale). I'd really love to have a way to tell Google to only show English-language hits.
Just append `&hl=en` to the URL. This should work.
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.
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.
That would be great, I'm living in Sweden and I prefer english hits as they're usually more relevant, unless I google something swedish that is.
> This is a completely irrelevant document.
This is NOT true. W3C vs WHATWG is a "political" issue. Saying either group publishes completely irrelevant documents is misleading.
This is NOT true. W3C vs WHATWG is a "political" issue. Saying either group publishes completely irrelevant documents is misleading.
The W3C document may be relevant to some small minority but the majority of people developing using HTML5 are targeting a set of clients that mostly or entirely follow the WHATWG's version in their actual implementations, and this is what defines relevance.
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.
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.
Right, everything is relevant to someone. But the grandparent was talking about what is relevant to browser vendors (and thus web developers), in which case it's pretty clear.
There are developers who solely rely on W3C recommendations to implement renders, parsers, and other standards-conforming mechanisms, widely because they provide actual versioning rather than a living standard. How clear this is to actual implementors is a matter of debate and preference.
Can you list some of these tools so that I can avoid using them, as they likely contain bugs that are fixed upstream in whatwg/html?
WHATWG is a bug.
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.
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.
> That’s the worst possible way to define a standard.
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.
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.
Well, there’s another solution.
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?
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?
"You write a standard, and get everyone to agree on it, before implementing it."
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.
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.
Uh, POSIX is generally considered a decent standard and has had great success, especially when compare to what it replaced.
> waterfall concept is considered bad taste in the web world
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."
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."
WHATWG specs aren't "it's kind of this or that". They're more like "it's exactly X, in 20 detailed steps of excruciating detail, and if X is a legacy feature we're sorry that it's kind of weird.
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.
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.
> 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.
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.
WHATWG HTML and W3C HTML both define a valid syntax for content, as well as parsing rules that cover everything, even error cases. Postel's Law states: "Be conservative in what you do, be liberal in what you accept from others.". Modern HTML standards codify this rule in a serious and detailed way. I think Jon Postel knows more about real standards than you do.
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.
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.
> That’s the worst possible way to define a standard.
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.
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.
Well, then stop using curl, cause that’s not compliant with the WHATWG standards.
> 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?
> 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?
Breaking 0.03% of the web is one thing, breaking larger parts of it starts to have far more dramatic effects. Many of the "worst" parts of the web are some of the most pervasive: well over 90% of the web relies on non-conforming HTML being parsed, much of the non-English speaking world relies on some of the really whacky behaviour around URL serialisation/parsing with different encodings, etc.
> 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.
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.
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.
> Attempts to define HTML syntax strictly (like DTD-based HTML 4 and earlier, or like XHTML) result in parsers that can't parse websites.
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.
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.
But the W3C spec is essentially a snapshot of the WHATWG, so I don't see how this is relevant in a discussion of whether a tool should use one or the other spec.
The W3C HTML specs are pretty much irrelevant for anyone wanting to write a web browser, or author content designed to be consumed by web browsers.
From section 1.5:
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!
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!
I think about this when I am using XMLHttpRequest in a web worker, and can't actually get an XML document back because you don't have access to an xml parser because there's no dom in web workers.
Why would you use XMLHttpRequest in a web worker? Why would you not just delegate working with the result to a web worker? The requests shouldn't dispatch any faster.
only point here is it was it was explicitly created for getting back an xml document (by microsoft, outside of any standards body, no less) while 99% of the time it's returning text or json, and in a web worker this XML tool literally can't return an XML document at all.
It can also fetch content over FTP in most browsers, in which case it isn't necessarily an HTTP tool either.
What you're saying is technically true, but only because the XML classes are historically also (unfortunately) DOM classes. It's too bad that XML DOM can't be made into Transferrables (losing their DOM'iness) in modern browsers and thus usable in Web Workers. I suppose XML isn't that widely used in the browser, so that would never happen.
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).
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).
> This specification should be read like all other specifications. First, it should be read cover-to-cover, multiple times. Then, it should be read backwards at least once. Then it should be read by picking random sections from the contents list and following all the cross-references.
Not sure if this is serious. https://www.w3.org/TR/2016/REC-html51-20161101/introduction....
Not sure if this is serious. https://www.w3.org/TR/2016/REC-html51-20161101/introduction....
It's mostly an import of the whatwg spec, which gets whimsical at times.
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.
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.
I don't think it is. It reminds me of something I've read before. I immediately thought of Hitchiker's Guide, but can't find the reference so it might not be. Still, I have a very distinct feeling I've read this before.
Is there a document somewhere that summaries the proposed changes from HTML 5 to 5.1?
I found this table [1] that lists features specific to HTML 5.1 and their status in current versions of browsers.
[1] https://w3c.github.io/test-results/html51/implementation-rep...
[1] https://w3c.github.io/test-results/html51/implementation-rep...
I assume this document [1] may cover some changes.
[1]: https://www.w3.org/TR/2016/REC-html51-20161101/changes.html#...
[1]: https://www.w3.org/TR/2016/REC-html51-20161101/changes.html#...
Interesting that "Having title, or writing email to a friend does not make an img missing alt conformant." What if you write an email to an enemy? https://www.w3.org/TR/2016/REC-html51-20161101/changes.html#...
There is also a diffed single page HTMLs at github [0], (11 MiB download; quite surprised my Firefox managed to render it).
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...
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...
Chyzwar(1)
I have been thinking of the "HTML5" buzzword and its problems for a while now.
I have been thinking about where to go to lunch.
Care to elaborate? What specifically is wrong with HTML5? And how is it particularly worse than other offerings?
I don't think this is what yuhong was referring to, but there's a lot wrong with HTML5. Googling "w3c whatwg", as one commenter suggested, won't give you any real insight into the mess, but it will hint at it.
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.
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.
Those browser vendors are also members of W3C. That's not why W3C HTML5 is irrelevant.
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.
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.
I feel I have to point out that there are big problems that can be considered well by a group of experts in excruciating detail, that a rolling release does not help.
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!!)
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!!)
Hi there, one of the WHATWG HTML editors here.
> 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!)
> 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!)
So, when will the WHATWG finally fix the HTML standards?
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.
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.
Because it would not be useful to any real web browsers.
That’s not any justification – you standardize things so other people can easier work with them, create competing browsers, libraries, etc, and so more innovation happens.
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.
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.
"Don't break the web" is a hard constraint. Any solution you propose that violates this constraint is unacceptable.
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.
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.
> "Don't break the web" is a hard constraint. Any solution you propose that violates this constraint is unacceptable.
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.
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.
[deleted]
The major browser vendors are of course members, and participate - and the W3C does a lot more than HTML - but their implementations track WHATWG.
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).
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).
I think it's fair to say the situation is even more complex than that: being a W3C Member doesn't necessarily mean they've really had anything to do with the standard, as the majority of Members aren't in any given working group, and even then, the majority of members of any given WG scarcely participate. (For the sake of clarity going forward: a "Member" is a W3C member organisation, a "member" is a member of a given WG who is either a representative of a W3C Member or an Invited Expert. Yes, this is ridiculous.)
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.
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.
More precisely, the "versions" are entirely arbitrary and even "versioning" HTML for the purpose of buzzwords is a misnomer. You will notice that WHATWG don't version their standards.
I am talking about the buzzword. For example, <canvas> dates back to 2005, long before the term was commonly used in the first place.
I don't really follow; your example's not clear. HTML5 is a standard, regardless of when the <canvas> element was first standardized, or even implemented.
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.
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.
I'm horribly oversimplifying, but to see the full ugliness, just google 'whatwg w3c'