- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 19 Jul 2012 22:48:37 +0000 (UTC)
- To: whatwg@whatwg.org
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@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. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 19 July 2012 22:49:05 UTC