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

Re: spec development process was: vendor prefixing

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 21 Nov 2011 16:49:27 -0800
Message-ID: <CAAWBYDD0F=sieyHwyt4D_hZgv42Hrggfdd0tBZ+W5DecDyFHvw@mail.gmail.com>
To: Ojan Vafai <ojan@chromium.org>
Cc: Bjoern Hoehrmann <derhoermi@gmx.net>, www-style@w3.org
On Sat, Nov 19, 2011 at 10:06 PM, Ojan Vafai <ojan@chromium.org> wrote:
> I agree that CR state is a relatively unhelpful construct at this point. I'm
> fairly confident at least that Gecko, WebKit and Opera do not wait for a
> spec to enter CR state to implement it. It's less clear to me what
> Microsoft's position is.

We (the CSSWG, at least) don't *want* you to wait for CR to start
implementations.  That would be horrible.  We go to CR when we *need*
implementations to go any farther in spec dev (because we've done as
much as we can from a theorycraft perspective), and none are
forthcoming.  Impls during WD are great when a spec starts
stabilizing, though.  (We're moving to officially recognize the WD
sub-steps outlined in
hopefully so this can be indicated directly in the drafts.)

> Of course testing is important. I would support requiring a test suite in
> order to consider a feature stable. This gives vendors an incentive to
> contribute test suites so that a specific feature can be unprefixed. Also,
> it makes adding tests less daunting since you only need to worry one feature
> at a time.
> In my experience working on WebKit, I'm fairly confident that a feature
> cannot be considered stable without *at least* one vendor implementing it
> and that vendor will necessarily write tests as they implement that can be
> contributed back.
> In retrospect it wasn't at all accurate to say that the versioned spec would
> go to CR. Once a "released" spec is versioned and finalized, it's never
> modified again. It will be superseded by the next version of the spec 4
> months later.

I support the publication of heartbeat drafts every 4 months or
sooner, and even driving CRs that fast based on what's stabilized in
each draft.

Received on Tuesday, 22 November 2011 00:50:21 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:52 UTC