Re: spec development process was: vendor prefixing

* 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/

Received on Sunday, 20 November 2011 02:12:59 UTC