Re: W3C vs WHATWG specs

(continuing from blink-dev)

On Tue, 15 Apr 2014, Chris Wilson wrote:
> On Tue, Apr 15, 2014 at 2:23 PM, Tab Atkins Jr. wrote:
> >
> > ... whenever the W3C forks a WHATWG spec, they:
> >
> > * rarely if ever update the fork, so it drifts behind the WHATWG 
> > version by a significant amount (sometimes *years* - there are some 
> > W3C forks of WHATWG specs that were last updated in 2012, *when they 
> > initially forked*)
> 
> Well, certainly not true in HTML.

The HTML spec is often weeks or months behind.


> > * sometimes make incompatible edits without attempting to get it into 
> > the WHATWG version of the spec, and rarely if ever indicate this 
> > prominently, so implementors accidentally following the W3C fork 
> > implement incorrect things that are incompatible with what other 
> > browsers are doing
> 
> I'm not sure what "attempting to get it into the WHATWG spec" means, 
> precisely, nor why the W3C WGs would find that particularly a goal.

Well the alternative is to be actively forking a spec, which seems 
obviously bad.


> > * violate the spirit of their own refusal to allow forks of W3C specs, 
> > a decision which has been repeatedly affirmed by W3C management.
> 
> Making a conscious choice to be a one-way street is not the same as 
> violating the spirit of their refusal.

The W3C says "Forking a specification imposes high costs, and is therefore 
not recommended" (http://www.w3.org/2013/09/html-faq).

But then they do it. Over and over again.


> The WHATWG says it's fine to fork their specs

http://wiki.whatwg.org/wiki/FAQ#Isn.27t_it_bad_that_the_specs_have_forked.3F

| Isn't it bad that the specs have forked?
| Yes. 

It is critically important (not just here but in life at large) to 
understand the difference between something being _a right_, and something 
being _right_. In the USA, for instance, one has the right to blatently 
lie in political advertising. However, doing so is certainly dubious on 
moral grounds. Similarly, it's quite legal to smoke; however, from a 
health perspective, it's not a good choice. In the free software world, 
one has a legal right to fork software products; however, creating 
multiple forks tends to have negative consequences and is therefore 
broadly frowned upon. It's fine if you fork a project to reuse its code in 
a different way (e.g. the many forks of 2048 to make new variants of the 
game were considered fine), but it's considered quite different to take a 
project and then make a new one using the same code base competing with 
the original ().

Wikipedia: "there is a reputation penalty associated with forking"
 -- http://en.wikipedia.org/wiki/Fork_(software_development)

Jargon File: "Forking is considered a Bad Thing [...] accompanied by a 
great deal of strife and acrimony [...] There is serious social pressure 
against forking."
 -- http://catb.org/jargon/html/F/forked.html

There's a reason the history of software forks is littered with negative 
connotations -- the "Unix wars", Emacs vs XEmacs, XFree86/XOrg, KOffice/ 
Calligra, OpenOffice.org's various forks...

In the case of the WHATWG specifications, the licenses allow broad re-use, 
so that implementors can copy-and-paste text into their comment blocks, so 
that tutorial writers can copy-and-paste text into their documentation, so 
that experiments we haven't considered can spring up without inhibition, 
and so that, if the WHATWG stops being a good steward (like the W3C 
stopped being a good steward in the early 2000s), the next group of spec 
editors doesn't have to start from scratch.

However, forking and competing? That's not why the spec is reusable. It's 
plagiarism. Yes, I use that word intentionally. Taking someone else's work 
or ideas and passing them off as one's own.

Take this page:

   http://www.w3.org/html/wg/drafts/html/master/

It lists seven editors. What percentage of the spec do you think was 
written by each of those seven editors? What percentage of the spec do you 
think was _read_ by each of those seven editors?

At least on some of the other specs, they have the decency to put the 
forking editors last, though still with no real acknowledgement of the 
difference in effort between the various roles ("upstream WHATWG version" 
could really mean anything unless you're already in the know):

   http://www.w3.org/TR/dom/
   http://www.w3.org/TR/XMLHttpRequest/

But even on those, a casual observer won't realise they're looking at 
non-original work. For example, the XHR one just says:

   Copyright © 2014 W3C® (MIT, ERCIM, Keio, Beihang), All Rights Reserved.

The DOM one is dual licensed with one license being CC-BY, it's not at all 
clear who the attribution should reference; it later says:

   This document is published as a snapshot of the _DOM Living Standard_.
   This document was published by the HTML Working Group as a Last Call
   Working Draft. [...] This document was produced by a group operating 
   under the 5 February 2004 W3C Patent Policy.

...and it has a big "W3C" stamp at the top. How is a casual observer to 
guess that what the above really means is "This document was written by 
someone working outside the W3C, and we then took a copy that we're not 
maintaining"? How is a casual observer supposed to know that "produced" 
here really is inaccurate boilerplate?


(Then there's the silent changes. For example, take this spec:

   http://www.w3.org/TR/webstorage/

...supposedly, according to the header, I'm the sole editor. Now look at 
the references, specifically the [HTML] line. I guarantee I didn't write 
_that_ reference. Compare it to the W3C-branded draft I publish: 

   http://dev.w3.org/html5/webstorage/

Stuff like that is all over the place. For example, see this spec's 
[HTML] reference:

   http://www.w3.org/TR/XMLHttpRequest/

Compare it to the [URL] reference, though. Makes you wonder why they had 
to change the [HTML] one -- I'm sure Anne's original version of that spec, 
before they forked it, didn't have that change.)



> the W3C avails themself of that privilege.

Yes, of that there is no debate. The question is merely whether that is an 
appropriate thing to do, given that all the original editors in question 
have repeatedly asked the W3C not to do so. I mean, it's not like our 
views on this are secret. We've asked Jeff Jaffe directly. We've asked the 
relevant working groups during their meetings. We've posted about it on 
the mailing lists, we've talked about it in person, we're talked about it 
on IRC. There's the WHATWG FAQ entry I cited earlier.


> The W3C does NOT say it's fine to fork THEIR specs, out of concern that 
> precisely what the WHATWG does would happen

Actually the DOM spec says it's fine, by your reasoning, since it has a 
CC-BY license.


> that a third party would attempt to wrest the "definitive" title from 
> them.

Note that the original HTML work at the WHATWG happened without any 
license-preventable textual forking.


> I would hope the W3C adds value to their versions of WHATWG specs, 
> driven by their consensus work mode, and intellectual property policy*; 
> if none, then I would expect the actors to participate in the WHATWG 
> instead.

One would hope. Most people who contribute to the forked specs have indeed 
moved to contributing in the WHATWG sphere. This hasn't stopped a small 
number of people from causing rampant confusion by using the W3C brand to 
give their forks prominence.


> * I would point out that the lack of a coherent IP policy prevents some 
> actors from participating, and likely always will.

The WHATWG patent policy is the W3C Community Group policy, which is more 
coherent than the IETF policy.


On Wed, 16 Apr 2014, Si Robertson wrote:
>
> Google and Mozilla, get together and form a new standardization group, 
> boycott the existing ones and clean this mess up :-)

That's how the WHATWG was started in the first place. :-)


On Wed, 16 Apr 2014, Glenn Adams wrote:
> 
> This is why I previously stated that the WHATWG does not follow a 
> consensus process. It endows certain individuals with the privilege of 
> speaking for the entire community, whether some or or all of that 
> community agrees with the results.

The editors of WHATWG specs don't speak for any community. They merely 
produce documents which they then hope will be considered good by the 
relevant implementors.

Consensus is not a useful value in Web spec development, because it 
doesn't accurately reflect the power dynamics at work. In practice, 
implementors have the ultimate say, not spec editors, not authors, not 
users, and not interested bystander standardistas. The W3C and the WHATWG 
thus have no power. (The WHATWG is built around that realisation; the W3C, 
however, is built no the assumption that it does have power. That's how it 
ends up making mistakes like RDF, XForms, or XHTML2.)

XForms was developed with consensus. On the broad design strategy, it even 
had unanimous consensus. In the formative years of that group, certain 
individuals pushed for a particular design strategy, and those who 
disagreed, which happened to include key browser vendor implementors, left 
the group. The result: a specification which had unanimous consensus in 
the working group, and majority support amongst the W3C Advisory 
Committee, and which got zero support from browser vendors. Spec DOA.

sXBL was developed with consensus. The spec was formed in a subgroup of 
the SVG group which -- probably due to the rather complicated nature of 
the work -- eventually dwindled to three people: me, a representative from 
a company that is not a browser vendor, and a chair who did not have a 
neutral point of view. The work continued for months in the form of weekly 
multlihour phone calls where painfully little progress was made; 
eventually, when the three of us finally deadlocked, the SVG group put the 
issue on their agenda and I planned to dial in to make my case. At the 
last minute (and while I was asleep), the meeting time was moved up, and I 
thus missed the meeting. During that meeting, Consensus was announced.

sXBL never went anywhere.

(I gave up on sXBL at that point, and rewrote it into XBL2. That didn't go 
anywhere either, because it was too much for browser vendors to adopt in 
one go. The idea later evolved into Web components, which is going through 
a W3C working group with a very different membership.)

All of this is to say: I don't say that consensus is worthless for 
developing Web specs on a whim. I've been doing this for 15 years now. 
I've been involved in groups with a wide variety of development 
methodologies. A single responsible editor is not ideal (it depends a lot 
on the quality of the editor, for one), but consensus is no panacea 
either. It leads to multiplication of credit and dilution of blame ("I 
made that! Oh I didn't do that part, that was someone else's fault"), it 
is too trivially subverted (just stack the committee), it doesn't scale 
(witness the disaster that was the 1000+ member HTMLWG when it was still 
really active), it leads to least-objectionable compromise solutions 
rather than allowing specs to take risks with potentially great solutions, 
it is very vulnerable to the "echo chamber" effect where people who 
disagree with vocal participants get pushed out and inconvenient (but 
pertinent) feedback gets ignored, and it's really slow.

More on this topic: https://plus.google.com/+IanHickson/posts/4MrPNJzE8vV

Also, note that consensus is actually not the ultimate decision making 
process at the W3C. The final call on everything is made by Tim. The 
WHATWG, on the other hand, leaves the final call with the editor, but 
gives a small group of people the authority to kick editors out if they 
get out of hand (which has never happened so far). This means that editors 
get the final say only so long as on the balance they make good calls.

(Of course, in both cases, as noted before, the real final say is with the 
implementors. It doesn't matter if the spec is written with consensus or 
with a single decision maker, if the implementors ignore it in the end.)


> Even though I have a lot of respect for the technical output of these
> individuals, I don't always agree with their position, conclusion, or
> resulting work.

Even _I_ don't always agree with the conclusions and resulting work that 
I'm responsible for. There's TONS of stuff in the HTML standard that I 
think is terrible and horrible. Unfortunately for me, my opinion really 
doesn't enter into many of the decisions that I have to make as editor.

These things aren't even limited to pure implementation specifics; I even 
disagree with some authoring criteria (where one would imagine I have more 
latitude). For example, I think it's silly that HTML allows "<br 
xmlns="http://www.w3.org/1999/xhtml"/>" given that the trailing "/" and 
the "xmlns" attribute have no effect. (You can tell that that's how I feel 
because of the way the relevant spec prose is phrased -- "In HTML, the 
xmlns attribute has absolutely no effect. It is basically a talisman." and 
so on. Some of the original prose I had around these things were even more 
opinionated; I've dialed it back a bit over the years.) However, 
compelling arguments were made that were stronger than the arguments I 
could put forward and thus the features made it in. Same with how style="" 
is allowed on all elements (I wanted to limit it to only <font> elements), 
or the way <div> is allowed (I wanted to drop it), or the headers="" 
attribute on table cells (whole centithreads have I participated in 
debating that issue). The list goes on; see, e.g.:
   http://lists.w3.org/Archives/Public/public-html/2009Jun/0714.html).

Do you always agree to everything that the W3C does?


> And I have no recourse and no due process when it comes to resolving 
> differences or even in insisting that they listen to my objections or 
> those of anyone else.

I guarantee a response to every substantial piece of feedback sent to the 
WHATWG list regarding a spec that I maintain. You might not like the final 
decision, but you cannot say that I won't listen. I go out of my way to 
listen to, and even seek out, objections.

What is your recourse at the W3C when Tim makes a Formal Objection call 
that you disagree with?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'