W3C home > Mailing lists > Public > www-style@w3.org > November 2011

Re: spec development process was: vendor prefixing

From: timeless <timeless@gmail.com>
Date: Wed, 30 Nov 2011 18:37:49 -0500
Message-ID: <CAACrNNdg2AAoZHZa69Q8KVSHf6e8JPKe3+z+tGiL=6_LkOQUHw@mail.gmail.com>
To: Yehuda Katz <wycats@gmail.com>, Sylvain Galineau <sylvaing@microsoft.com>, Henri Sivonen <hsivonen@iki.fi>, "www-style@w3.org" <www-style@w3.org>
I think it depends on the implementer and the WG. There are definitely
some implementers, especially when they aren't members of a given WG,
who won't consider a spec until LC and won't try implementing until
CR. There are hundreds of specs and most vendors are resource
constrained. For the CSS WG, things are possibly somewhat different,
you only have a handful of upstream vendors and the barrier to entry
for someone honestly starting from scratch is so high that no one does
it. *Apple started from khtml, Google started from WebKit, Nokia
started from both Gecko and WebKit (actually multiple times).

If you look at individual CSS specs and consider that one vendor
occasionally proposes a spec after having already implemented it, you
could treat their proposal as an LC, as in reality it's already
leaking to the web. It's likely that one of the other main vendors
won't actually start implementing until some of the others have pushed
it through a number of LCs. A point is reached where the number of
changes per iteration decreases, this could be considered CR, at which
point one of the major vendors may do its first impl. From this
perspective, there are vendors who do benefit from a theoretical CR
state, but who can't use the real CR state because the CSS WG doesn't
get there.

On 11/30/11, Yehuda Katz <wycats@gmail.com> wrote:
> Yehuda Katz
> (ph) 718.877.1325
>
>
> On Wed, Nov 30, 2011 at 8:14 AM, Sylvain Galineau
> <sylvaing@microsoft.com>wrote:
>
>>
>> [hsivonen:]
>> >
>> > On Sun, Nov 20, 2011 at 2:08 AM, Ojan Vafai <ojan@chromium.org> wrote:
>> > > Give it a version number and call it a CR.
>> >
>> > I think it's not a good idea to continue to couple unprefixing with CR.
>> > There's now momentum to unprefix certain properties. Changing the
>> > discussion from something concrete and actionable (whether to unprefix
>> > them) to readjusting when to enter CR risks losing that momentum,
>> > because
>> > it's harder to change the W3C Process than it is to change the prefixing
>> > policy or to make ad hoc exceptions to the prefixing policy.
>> >
>> > The CR stage in the W3C Process is currently based on fiction (the
>> > notion
>> > that implementations start when the spec enters CR).
>>
>> Of the things that puzzle me in the process, the claim that CR is a 'call
>> to implementation' ranks way up the list. If you reach CR with zero
>> implementation experience the CR status of your spec is simply not
>> meaningful:
>> the odds of it not going back to WD upon first contact with real code are
>> extremely
>> low vs. a spec that reaches CR on the back of several prefixed
>> implementations,
>> author feedback etc.
>>
>
> Agreed. Is it normally the case the implementors even wait for CR before
> implementing, or is the entire concept a total fiction?
>
>
>>
>> But this puzzlement is also a consequence of my assuming as a goal that CR
>> should
>> be entered once since it also relates to test suite production, dropping
>> prefixes
>> based on IRs etc i.e. a number of final steps on the way to PR and REC.
>>
>> It could simply be that CR is overloaded with conflicting intents.
>>
>>
>

-- 
Sent from my mobile device
Received on Wednesday, 30 November 2011 23:38:17 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:46 GMT