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

Some commentary on the HTML5 / WHATWG changes

http://www.xmltoday.org/content/inevitable-forking-html

On 23 July 2012 16:44, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

> 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.   `._.-(,_..'--(,_..'`-.;.'
>
>