4 ms·

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 num

by LukeShu 10y ago

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.

domenicd 10y ago
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-108606731 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 https://github.com/whatwg/html/pulse might give a reasonable overview. Compare to https://github.com/w3c/html/pulse https://github.com/w3c/html/pulse. Some relevant corroborating links: - https://annevankesteren.nl/2016/01/film-at-11 https://annevankesteren.nl/2016/01/film-at-11 when this all started - https://wiki.whatwg.org/wiki/Fork_tracking https://wiki.whatwg.org/wiki/Fork_tracking monitoring the ongoing copy-and-paste-induced confusion - https://github.com/w3c/html/issues/364 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/19fcaf241f4417b2078bc26bf957b196e1d76154 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!)
- deleted 10y ago
  [deleted]
- kuschku 10y ago
  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.
  - yuhong 10y ago
    Because it would not be useful to any real web browsers.
    - kuschku 10y ago
      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.
  - jdlshore 10y ago
    "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.
lucideer 10y ago
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).
gsnedders 10y ago
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.
clockwerx 10y ago
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!!)

by LukeShu 10y ago

domenicd 10y ago

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-108606731 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 https://github.com/whatwg/html/pulse might give a reasonable overview. Compare to https://github.com/w3c/html/pulse https://github.com/w3c/html/pulse. Some relevant corroborating links: - https://annevankesteren.nl/2016/01/film-at-11 https://annevankesteren.nl/2016/01/film-at-11 when this all started - https://wiki.whatwg.org/wiki/Fork_tracking https://wiki.whatwg.org/wiki/Fork_tracking monitoring the ongoing copy-and-paste-induced confusion - https://github.com/w3c/html/issues/364 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/19fcaf241f4417b2078bc26bf957b196e1d76154 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!)

deleted 10y ago
[deleted]
kuschku 10y ago
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.
- yuhong 10y ago
  Because it would not be useful to any real web browsers.
  - kuschku 10y ago
    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.
- jdlshore 10y ago
  "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.

lucideer 10y ago

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).

gsnedders 10y ago

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.

clockwerx 10y ago

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!!)