W3C home > Mailing lists > Public > public-html@w3.org > June 2015

Re: Proposed split of the HTML specification

From: Robin Berjon <robin@w3.org>
Date: Thu, 25 Jun 2015 11:47:01 +0200
Message-ID: <558BCE15.2010900@w3.org>
To: Paul Cotton <Paul.Cotton@microsoft.com>, "Philippe Le Hegaret (plh@w3.org)" <plh@w3.org>
CC: Travis Leithead <travis.leithead@microsoft.com>, "HTML WG (public-html@w3.org)" <public-html@w3.org>, Adrian Bateman <adrianba@microsoft.com>, Erika Doyle Navara <Erika.Doyle@microsoft.com>, "chaals@yandex-team.ru" <chaals@yandex-team.ru>, Steve Faulkner <faulkner.steve@gmail.com>, Sam Ruby <rubys@intertwingly.net>
Hi Paul,

good questions.

On 24/06/2015 16:24 , Paul Cotton wrote:
> I have some additional questions to add to Robin's questions.
> Q5:  Robin's proposed split [2] appears to apply to only HTML 5.1,
> will it also apply to HTML 5.0 for maintenance purposes?

Any direct maintenance of the HTML 5.0 document is going to be labour 
intensive because none of it can be automated. As you know, my 
preference is always going to be towards automating as much of the 
knuckleheaded stuff so that contributors can focus on technical issues.

So my preference leans strongly towards moving forward with the split 
5.1 document family. One advantage is that they don't need to move 
forward as a block (except probably for the FPWD). This means that if 
there are crucial fixes in some of them, they can be taken to Rec 
relatively faster.

> Q6. If the answer to Q5 is No, then should initial changes to the
> HTML 5.1 modules be limited to maintenance fixes and outstanding bugs
> [1] so that we can publish HTML 5.1 ASAP as a maintenance release of
> HTML 5.0?

I suspect that this will happen naturally, and we can further encourage 
it. My expectation is that larger features, unless they are somehow 
intricated with existing features, will happen in new, separate 
documents anyway.

The split documents have a fair amount of small fixes, and a lesser 
amount of newer features. We can identify which can be fast-tracked (if 
needed) on a case-by-case basis.

One advantage of accepting the split sooner rather than later is that a 
number of our existing bugs have their fixes pending on the split. So 
the go-ahead will enable fixes to happen.

> Q7.  If the answer to Q5 is Yes, then how will the various editorial
> and bug fixes extracted from the WHATWG upstream version that have
> been added to HTML 5.1 since it was first published in Nov 2014 be
> "back-ported" to the split out parts of HTML 5.0?

If we were to do that, it would be a largely manual process. We'd have 
to either A) manually apply the fixes one by one, or B) start from the 
current copy and remove things not in 5.0. The splitting can then be 
automated, but we're looking at weeks of work if we do this.

> Q8.  Are we going to unhook the production of HTML 5.1 from the
> upstream WHATWG version?  If so when?

As soon as we're split, we're unhooked.

Robin Berjon - http://berjon.com/ - @robinberjon
Received on Thursday, 25 June 2015 09:47:05 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:46:13 UTC