Re: spec development process was: vendor prefixing

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.

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.

Ojan

On Sat, Nov 19, 2011 at 6:12 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:

> * Ojan Vafai wrote:
> >The vast majority of the pain and difficulty people associate with vendor
> >prefixing is not that we prefix, but rather how long it takes before we
> can
> >unprefix. Rather than continue to debate the cost/value of prefixing, we
> >should instead focus on the timely removal of prefixes. Here's one
> proposal
> >for addressing this.
>
> I would think the Working Group participants know that if they move a
> draft to Candidate Recommendation, it will stay there so long that it
> will have to be moved back to Working Group status to add features as
> it would be rather pointless to start a new version of the module and
> park that as a Candidate Recommendation next to the earlier version.
>
> The reason for that is that the Working Group would like to have test
> suites with decent coverage and implementation evidence before they
> submit the document for publication as a Recommendation ("standard").
> You don't explain how your proposal would lead to test suites and im-
> plementations that pass all the tests in them, so you are essentially
> arguing that the Working Group should drop tests as a requirement.
>
> It does not matter whether you call the document that everybody uses
> to implement features "Candidate Recommendation" or "Recommendation"
> if the specification is good and everybody implements the features
> properly; the test suite requirement is there because usually either
> the specification isn't actually that good or implementations aren't.
>
> If that has changed, there is no reason to have the requirement, and
> the Working Group would essentially automatically use a process like
> you describe consider that it took only a year and a half to go from
> the CSS Level 1 Recommendation to the CSS Level 2 Recommendation.
>
> If it hasn't changed, and considering that even decade-old features
> like border-radius are buggy even today I doubt it has changed much,
> we would rather need a way that would put pressure on browser vendors
> to contribute to the vendor-independent test suites. That, too, would
> change the dynamics of the Working Group automatically. If a document
> is through last call with only applause and all features have proper
> tests, multiple independent browsers reasonable pass them all if you
> prefix the property names, then the Candidate Recommendation thing
> becomes redundant, you could go straight to Proposed Recommendation,
> and considering current release schedules, the Recommendation would
> be published as the unprefixed implementations become available.
>
> We could start by making charts how many tests for CSS3 modules have
> been contributed by Apple and Google and other vendors this year.
>
> >Then spend a short amount of time (e.g. a week) making sure that spec 2
> >makes sense with the unstable parts stripped (e.g. cross-references all
> >exist, terms are all defined, etc). Give it a version number and call it a
> >CR. You now have a stable, versioned snapshot for browser vendors to
> >implement unprefixed.
>
> Vendor prefixes for features on the standards track are there so the
> initial implementations of them do not cause too much harm. If there
> are no implementations when the W3C calls for implementations, then
> you cannot implement them without a prefix and be a good netizen at
> the same time. If there already are implementations, browser vendors
> can just wait a little while until test suite and implementation re-
> ports are published before they remove the prefixes. Browser vendors
> control how long that little while is, as they would be writing the
> tests and the implementation reports for the most of it.
>
> Note that the Candidate Recommendation phase is a sort-of compromise,
> implementers used to say they won't release implementations until the
> specification is stable, and the standards body would like to have
> proper implementation experience before they declare stability. This
> isn't a problem for CSS at the moment as browser vendors happily im-
> plement unstable features via vendor prefixes, so there isn't really
> a point in having Candidate Recommendations, other than parking the
> drafts there while hoping for someone to contribute tests some day.
> --
> Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
> Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
> 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
>