Re: spec development process was: vendor prefixing

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
<http://fantasai.inkedblade.net/weblog/2011/inside-csswg/process>,
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.

~TJ

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