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

FYI: Some developments in HTML5

---------- Forwarded message ----------
From: Ian Hickson <ian@hixie.ch>
Date: 20 July 2012 00:48
Subject: [whatwg] Administrivia: Update on the relationship between the
WHATWG HTML living standard and the W3C HTML5 specification
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.   `._.-(,_..'--(,_..'`-.;.'