vendor prefixes: co-cascading

I have an idea for vendor prefixes. I don't know if this is new or really old (so much is written about it...), let me just give it a try. I'll try to make it short.


1.       Browsers should support *both* prefixed and unprefixed versions of new properties.

2.       It is OK to support unprefixed properties as soon as there is at least a reasonably detailed spec. First WD should be fine.

3.       Prefixed and unprefixed versions of same property cascade together: when both are specified, the last one (or most specific one) wins, as if it was same property.

4.       Vendors make their own decisions on when and how to change, retain or abandon their proprietary properties. Timeframes and criteria for these changes should not be much different from current practice.

5.       Vendors are expected to regularly update the syntax and behavior of unprefixed properties. These can be considered "W3C experimental" until spec is very stable.

6.       Authors have a choice to favor prefixed or unprefixed properties, based on spec and implementation status and purpose of the content.

For example, this is something that might be authored early in spec development

font-weight: thin;
-a-font-weight: 400;
-b-font-weight: light;

ORDER MATTERS: browsers A and B will always use their prefixed versions, regardless of status of the standard. But browsers C and D will work too, as long as they support the spec version chosen by author.

A few years later, with spec finalized, a web page may have something like this:

-a-font-weight: 400;
font-weight: lighter;

all current browsers support the unprefixed syntax. "-a" setting is for a corporate customer who has a lot of cheap machines that will never upgrade.  It works because the old "A" browser doesn't understand 'lighter' and will discard that property.

I fact, I don't think I am proposing anything that wouldn't work today (or perhaps almost work). The only real change is "feel free to implement anything that has a name, but don't promise anyone it won't change"

DOM may be harder, but the same approach should work:  a smart script should test for prefixed version first if the feature is unstable or just go for unprefixed if the feature has never changed.

What do you think?

Alex