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

spec development process was: vendor prefixing

From: Ojan Vafai <ojan@chromium.org>
Date: Sat, 19 Nov 2011 16:08:57 -0800
Message-ID: <CANMdWTtuyXMYBMEcL9iSu+H94MAn6vXFJ-nsKSoYgkcH6F5MOQ@mail.gmail.com>
To: www-style@w3.org
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.

TL;DR version: Treat spec writing as a software development project. All
your work goes on trunk, then once in a while you cut a branch, work out
the small number of kinks in the branch to make it releasable and *then*
give it a version number.

There are many ways you could do the above. Here's one. Have a trunk (i.e.
draft) spec that contains all the features (stable and unstable). As
features are considered stable, annotate them appropriately.

At fixed points every year (e.g. every 4 months) create two forks of the
1. A snapshot of the spec in its entirety. This is exclusively to give
companies an opportunity for intellectual property rights evaluation.
2. A snapshot of the spec with all the unstable bits stripped.

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.

The work involved in creating snapshot 2 is almost entirely scriptable, so
the overhead of bringing the stable features to CR is negligible.

While this is going on, all your work on trunk continues uninterrupted
without any concerns about what version of a spec a feature should go into
or whether the spec as a whole can go to CR because of one or two possibly
unstable features.

The main point here is that the *default* is to move stable features to CR
on a regular basis. If the editors of a spec disappear (as happens
frequently), we'll at least get the stable features in a releasable,
unprefixable state. If there editors stay around, we still get the stable
features unprefixable faster.

Received on Sunday, 20 November 2011 00:09:54 UTC

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