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

Re: Editorial patches staged for merge week 49

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Sun, 9 Dec 2012 16:28:34 +1100
Message-ID: <CAHp8n2=bgr0-0BvhQanzX1TeuzZS1z3xmY+k6DkEAM0_79_4Wg@mail.gmail.com>
To: Sam Ruby <rubys@intertwingly.net>
Cc: public-html-admin@w3.org
On Sun, Dec 9, 2012 at 1:45 AM, Sam Ruby <rubys@intertwingly.net> wrote:

> On 12/08/2012 04:40 AM, Silvia Pfeiffer wrote:
>> So, wrt extension specs: the way I understand them is that they are for
>> the HTML5 spec: they specify features that somebody hopes to still get
>> into HTML5, rather than HTML5.1 [1].
>> [1] http://dev.w3.org/html5/**decision-policy/html5-2014-**plan.html<http://dev.w3.org/html5/decision-policy/html5-2014-plan.html>
> I disagree.  See:
> "During this process, we will encourage modularity as a preferred way to
> approach introducing new features into the 5.1 release."
> Reference:
> http://dev.w3.org/html5/**decision-policy/html5-2014-**
> plan.html#html5.1-milestones<http://dev.w3.org/html5/decision-policy/html5-2014-plan.html#html5.1-milestones>
Sure, modularity is a good way to introduce big features. But what about
small features?

I don't think we want to go to the extent of making every single patch an
extension spec. All new content in a HTML5.1 spec is only proposed until
the spec goes to CD - actually really until it goes to REC, but with more
rigorous weeding of features from about CD on. I don't see it practical
until CD to work with an extension spec for every change, or even every new
small feature.

Any big feature - such as the introduction of encrypted media - is
certainly better introduced through a separate spec. However, there is a
difference between a modular new spec and an extension spec as for HTML5.

Received on Sunday, 9 December 2012 05:29:22 UTC

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