- From: Ojan Vafai <ojan@chromium.org>
- Date: Sat, 19 Nov 2011 16:08:57 -0800
- To: www-style@w3.org
- Message-ID: <CANMdWTtuyXMYBMEcL9iSu+H94MAn6vXFJ-nsKSoYgkcH6F5MOQ@mail.gmail.com>
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. DETAILS: 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 spec: 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. Ojan
Received on Sunday, 20 November 2011 00:09:54 UTC