Re: vendor prefixes: co-cascading

On Thu, Nov 17, 2011 at 4:59 AM, Alex Mogilevsky <alexmog@microsoft.com>wrote:

>  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 the most part, the vast majority of authors are (and should be!)
completely ignorant of specs. They only know and care about
implementations. If the code works, they'll use it. Unless there's
something specifically forcing the feature to be clearly unstable (e.g. a
name or namespace), authors will rely on it and then we'll be stuck with
it.

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