"-draftX-" prefix

My previously posted idea (http://lists.w3.org/Archives/Public/www-style/2011Nov/0346.html) wouldn't work. Sorry for not commening on all replies... the key problem there (or with any option that uses unprefixed names for draft specs) is that most people don't read specs, so when a new unstable property looks like all other properties it will create all kinds of new issues.

So, what can we do? Anything? Brian Manthos and I had a brief brainstorming on options and I think what we liked is somewhat different from earlier proposals. See below...

Let's try to look systematically at what are the ways to express something non-standard in CSS:


1)      Vendor prefixes: "-vendor-foo:50%"

Nobody is asking for more vendor prefixes and we can't regulate those anyway, but it is worth noting that there are two major types of use:



a)      Experimental: not intended for broad use, introduced in test builds; can (and do) change often

b)      Proprietary: used for stable features that are not part of any standard (although commonly in a draft standard); change rarely
Once a proprietary feature is not truly experimental and gets a significant use, browsers are very reluctant to change it. That makes prefixed properties in effect versions of standard (but for one UA only).


2)      Unprefixed: "foo:50%"
That is the "living standard" approach. It has been proposed and shot down many times, I don't want to even summarize the issues.


3)      W3C prefix: "-w3c-foo:50%" or "-css-foo" or "-draft-foo" etc.
It is the same approach as "experimental" proprietary feature, and CSSWG seemingly should have the right to be its own vendor.
But... just as vendors do, CSSWG would have to transition properties from experimental to proprietary (stop changing the syntax) when they get used "widely enough", which would be very bad for standards development

And the option we like:


4)      Versioned W3C prefix: "-draft1-foo:50%" or "-wd1-foo" etc.
If anything can work that allows use of draft specs without vendor prefixes, it must be this one. It allows cross-browser authoring for new features, yet it doesn't compromise spec development process.

David Singer has proposed it here: http://lists.w3.org/Archives/Public/www-style/2011Nov/0358.html. It had some discussion and some opposition; it does look like a good solution to me, if done right.

THE TRICK TO MAKING IT WORK IS HOW VERSIONED PREFIXES ARE PROCESSED AND MAINTAINED. I think this part is new here.

PARSING AND CASCADING

The version number in draft property is not part of property name. It is parsed away and used an instruction for UA for how to interpret the value.
For example:

                -draft2-foo:50%

means "-draft-foo:50%" applied according to v2 of the draft.
It could also be written as

                -draft-foo[2]:50%
or
                -draft-foo:50% !v2;
or even
foo:50% !v2;
(the last one probably not a good idea, as it locks the name "foo" and it may be harder to reuse in case this draft is abandoned)

With this approach,

*         UA doesn't need to support all versions of the property. It parses versions it chooses to understand, then let them cascade normally

*         Values of unsupported version are ignored

Note that this is not all that different from current situation. UAs support one vendor-prefixed version at a time, which is exact equivalent of supporting just one of the drafts using above rules.

DOM

In script, there is an additional challenge to check for feature support and to get values in specific version of syntax. Something like this can happen there:

if (DoYouSupport("-draft-foo", 3))
{
element.style.draftFoo = "50% !V3";
}
if (DoYouSupport("-draft-foo", 3))
{
element.style.draftFoo_3 = "50%";
                // or
element.style.v3.draftFoo = "50%";
// or
element.style.SetDraftProperty("draftFoo", 3, "50%");
}

(these are early thoughts, I am sure there are more elegant solutions for DOM)

BACKGROUND
In unlikely case that you are unfamiliar with recent discussions on this topic, I recommend reading these:
http://hsivonen.iki.fi/vendor-prefixes/
http://www.glazman.org/weblog/dotclear/index.php?post/2011/11/16/CSS-vendor-prefixes-an-answer-to-Henri-Sivonen
http://infrequently.org/2011/11/vendor-prefixes-are-a-rousing-success/
http://lists.w3.org/Archives/Public/www-style/2011Nov/0271.html
http://lea.verou.me/2011/11/vendor-prefixes-have-failed-whats-next/

CAN THIS WORK?

I realize that the above is a fairly subtle variation on simply using "-draftX-" prefixes. Either way, other options seem even less likely.
Can we make something like this work? If not, it may be true that the only hope to fix prefix mess is to speed up spec progress in CSSWG...

Thanks
Alex