[whatwg] Administrivia: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification

[Ian Hickson]

If you've been happily ignoring the W3C's involvement with HTML these past 
few years, you can stop reading now. If you got a bunch of bugmail 
recently and want to know why, the explanation is below.


A few years ago (around 2007), we started working with the W3C on what we 
were then unofficially calling "HTML5", and officially calling "Web 
Applications 1.0". We renamed the specification "HTML5", and the W3C began 
publishing a copy of it as well. Not long after, the W3C side of this 
effort decided to split their version of the spec into subspecs (e.g. 
splitting out the 2D canvas API, server-sent events, postMessage, etc), 
and for a while we tried to match that on the WHATWG side. The result was 
an increasing confusion of versions of the spec, so we eventually went 
back to just having a single spec on the WHATWG side which contains 
everything I work on, which we now call the "HTML Living Standard". Over 
the years, this document and the various documents on the W3C side have 
slowly slightly forked, as documented at the top of the WHATWG spec.

More recently, the goals of the W3C and the WHATWG on the HTML front have 
diverged a bit as well. The WHATWG effort is focused on developing the 
canonical description of HTML and related technologies, meaning fixing 
bugs as we find them [1], adding new features as they become necessary and 
viable, and generally tracking implementations. The W3C effort, meanwhile, 
is now focused on creating a snapshot developed according to the venerable 
W3C process. This led to the chairs of the W3C HTML working group and 
myself deciding to split the work into two, with a different person 
responsible for editing the W3C HTML5, canvas, and microdata 
specifications than is editing the WHATWG specification (me). [2]

As part of working with the W3C, we have been using the W3C Bugzilla 
system to track bugs filed using the widget at the bottom right of the 
WHATWG specification. The W3C has kindly agreed to continue hosting the 
bugs filed on WHATWG specifications. Previously, however, since there was 
just one editor working on the W3C and WHATWG specs, we just had one set 
of bugs for both specs, and I processed them as if there was just one 
spec. With the fork, this is no longer tenable. Therefore, we have taken 
all the bugs that were previously filed in the W3C Bugzilla system on the 
HTML specs, and cloned them: one copy for the W3C, and one copy for the 
WHATWG. I will be going through the WHATWG bugs, and the new editor(s) for 
the W3C will be going through the W3C bugs. If you recently got a bunch of 
bugmail mentioning "operation convergence", that's what it was about. For 
more details on what exactly happened, see later in this e-mail.

How does this affect you?

* If you want to send feedback on the WHATWG specification: the easiest 
way is just to e-mail this mailing list (whatwg at whatwg.org).

* If you want to file a bug on the WHATWG specification: Use the tool in 
the WHATWG specification, and it will use the right component for you.

* If you want to use the W3C Bugzilla directly to file bugs or search for 
bugs on the WHATWG specification: Use the "WHATWG" product in Bugzilla. 
The component is "HTML" for the specification I edit; the product also has 
components for a few other specifications edited by, e.g., Anne.

* If you want to comment on a bug in Bugzilla in such a way that I see 
your comment: make sure you comment on the bug that's assigned to me. If 
the bug is in the "HTML WG" product, not the "WHATWG" product, it will be 
assigned to the HTML WG's editor and so I might not see it. (I'll be doing 
my best to track changes made on the W3C side, but I likely won't be 
tracking it down to the level of individual bug comments.)

This is a link to the currently open bugs on the WHATWG HTML spec:
https://www.w3.org/Bugs/Public/buglist.cgi?product=WHATWG&component=HTML&resolution

To track how much feedback is pending, I use this graph:
http://www.whatwg.org/issues/data.html

Details on "operation convergence":

The bugs used to be in two buckets: those filed on the W3C spec (in 
various components like "HTML5 spec") and those filed on the WHATWG spec 
(in the "other Hixie drafts" component). They were mostly all assigned to 
me, and I used to ignore the component [3]. I ran a pair of scripts 
recently in conjunction with W3C staff that cloned all these bugs. The 
first script took those bugs that used to be in the "HTML5 spec" 
components, made a new clone in the WHATWG product assigned to me, and 
reassigned the original bug to nobody. The second script took the bugs 
that were in the "other Hixie drafts" component, moved them to the 
"WHATWG" product, and cloned them into bugs in the "HTML5 spec" component, 
assigned to nobody. The bugs that are assigned to nobody today will in due 
course presumably be reassigned to whoever becomes the editor of the W3C's 
HTML5 specifications. This effort does not affect bugs filed in the 
future; I am still working with the chairs of the HTML working group to 
work out what our long-term plan should be for this going forward. The old 
"other Hixie drafts" component is now gone.

The changes described above are unrelated to the change announced in April 
regarding the WHATWG's adoption of the W3C Community Group mechanism, but 
together they mean we are now independent of the W3C HTML Working Group 
again, while still maintaining a working relationship with the W3C. [4]

My hope is that the net effect of all this will be that work on the HTML 
Living Standard will accelerate again, resuming the pace it had before we 
started working with the W3C working group.

If you have any questions, I encourage you to e-mail me privately or ask 
on the IRC channel (#whatwg on Freenode); process-related discussion is 
discouraged on this mailing list so that we can maintain a high technical 
signal to noise ratio.

-- Footnotes --
[1] or a few months after we find them... I'm about 6 months behind right 
now. Sorry about that. Working on it!

[2] http://lists.w3.org/Archives/Public/public-html/2012Apr/0204.html

[3] Actually I had bookmarklets for closing the bugs as "Accepted" and 
"Rejected" which, for bugs in the W3C HTML WG components, used the 
boilerplate required of me by the HTML working group process, and for bugs 
in the "other" component skipped the boilerplate. The HTMLWG only applied 
its process to bugs in their components.

[4] http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Apr/0240.html

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