W3C home > Mailing lists > Public > public-html-admin@w3.org > December 2012

Re: suggested process for adding new features to HTML 5.1

From: Charles McCathie Nevile <chaals@yandex-team.ru>
Date: Mon, 10 Dec 2012 15:01:08 +0100
To: "HTML WG administrative stuff" <public-html-admin@w3.org>
Message-ID: <op.wo3s76nvy3oazb@chaals.local>
On Sun, 09 Dec 2012 11:47:11 +0100, Steve Faulkner  
<faulkner.steve@gmail.com> wrote:

> Hi all,
> on recent threads [1], the subject of how and what new features (in this  
> case I am referring to the addition of attributes or elements) get added  
> to HTML5.1, has >arisen.
> The current situation appears to be:
> New features originating from the WHATWG spec can be added without a CFC  
> from the working group
I agree this is not a good idea, and don't believe it is the intended  
outcome. I support W3C's overall goal of not letting the WHAT-WG fork  
diverge where possible, but believe that new features should be proposed  
and accepted. A formal CfC would be clearer than including them in the  
current patch-staging email notifications.
> There is no clear path for features originating from other groups or  
> from within the HTML WG to be added to HTML 5.1.
Hmm. I *think* the clear path is via the extension specification  
mechanism. It is unclear in practice how to go from an extension spec to  
HTML (which is presumably why you address that question below :) ) The  
proposals for a  "main" element, possible approaches to working with  
responsive images, longdesc, and the work of the media task force are all  
candidates that will help understand how this process works in practice.

> I suggest that for any new feature (addition of an attribute or element)  
> or major change in a current feature (removal or redefining of its  
> semantics/function) >regardless of origin, that A CFC occur.

This makes sense.

> If a CFC passes without objection (objections are processed as per WG  
> process by the chairs), the addition may upon request be merged into  
> HTML 5.1. If there >are objections (upheld by the chairs) the feature  
> may be pursued as an extension spec subject to the usual WG process for  
> extension specs.

To clarify: If there is a Call for Consensus to include a particular  
feature in HTML, it makes sense to simply do so. If there is not  
consensus, it would still be possible to request publication as an  
extension specification.

> In the case where there are multiple overlapping new feature proposals  
> (example srcset and picture) that they be developed as extension specs  
> until consensus >emerges on one of the proposals, which then may be  
> added to HTML 5.1
Where there is not consensus on one approach, this makes sense. It is  
equally reasonable to decide later that an earlier decision to incorporate  
a draft was wrong, and change the model.

Of course as you get closer to Recommendation, the cost of doing this can  
be higher.

> In the case where an extension spec is developed that competes with a  
> feature currently in HTML 5.1 and is published as a FPWD, the feature in  
> HTML 5.1 is >pulled out of the spec and may be developed as an extension  
> spec
I disagree. I think it makes sense to allow the exploration of new  
features through extension specifications before the working group agrees  
to change the existing HTML specs. Pulling something out into an extension  
spec is real work, and unless or until the Working Group actively decides  
that it is no longer clear about wanting something that was in there, the  
simplest approach is to leave it alone.

> In the case where there is a feature developed as an extension spec that  
> has reached FPWD and with no competing proposals, upon request, the  
> feature  be >merged into HTML5.1
Again I disagree. This puts too much pressure on an exploratory draft,  
whose function should be to get a given feature specification to the level  
of spec quality where it could be incorporated, without prejudging that  

Allowing this automatic transition is likely to lead to the sort of  
arguments we have seen where people want to stop everyone else from even  
working on a proposal - one of the most anti-productive games of process  
politics I have seen in this environment.

> As for other features originating from the WHATWG, the editor of a  
> merged extension spec can continue to develop the feature via the spec  
> and changes are >pulled into HTML 5.1 subject to usual WG oversight.
Obviously, it is not up to this working group what the WHAT-WG does.  
Despite that, we have stated that we will aim for convergence where  
possible. I think our current patching process is a reasonable way of  
managing this for features where we have concluded that we want them.  
(Thanks Silvia for lots of work on this, Steve for actually regularly  
watching, and anyone who is anonymously doing the same).

> [1]  
> http://lists.w3.org/Archives/Public/public-html-admin/2012Dec/thread.html

Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
chaals@yandex-team.ru Find more at http://yandex.com
Received on Monday, 10 December 2012 14:01:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:37:32 UTC