Vendor-prefixes: an idea

Hi,

I know this is a controversial subject, but I have got an idea I wanted to 
share. I therefore invite you to read the mail even if you actually like 
vendor prefixes. I'm trying not to hurt anyone with this mail, I promise.

Vendor prefixes have advantages:

    - properties are out quickly, devs can use them if they really need it 
(+they can report bugs).
    - we can still change the property before standardization, no content is 
broken (at least, in theory).

Vendor prefixes have disadvantages:

    - authors don’t include a prefix for every browser out there, especially 
new/small ones; if they include unprefixed before CR (a lot do), the 
advantage of “we can change withtout breaking content” is lost.
    - the same prefix can be used by more than one browser (eg: webkit) with 
different implementations, which defeat the purpose.
    - browsers face pressure to support each other prefixes.
    - it isn’t clear enough property is a “beta” version.

Also, when a property changes of Module Level, this get tricky. The property 
exists unprefixed but maybe a prefixed version support more features than 
the unprefixed one. Or maybe some browser could extend the definition of a 
CR-property, unprefixed, and then developers don't even notice they use 
proprietary features. In both cases, this feels wrong.



Here’s an idea which can solve this problem: let’s introduce the 
“!vendor-draft” value modifier. I propose we use unprefixed properties from 
start, but with a token explaining which version of the property we built 
our CSS for.


@@ First iteration:

    selector {
        border-radius: 3px !webkit-draft;
    }

instead or

    selector {
        -webkit-border-radius: 3px;
    }

Advantage? Any browser which is not webkit but implemented border-radius in 
a way that is compatible with the “webkit draft” can support the 
declaration. This is different from vendor prefixes: other browsers don’t 
impersonnate webkit, they just acknowledge they support one specific 
property the way the webkit draft defines it. Browsers which are not 
compatible with that draft will just ignore the declaration. Browsers that 
change their implementation of a property are encouraged to iterate their 
"!vendor-draft" flag (using a version number, if appropriate).

We don't focus on vendors, we focus on specs. This is more logical.



@@ We can use standard fallbacks to specify prefered declaration (just like 
we do for css2 vs css3 unprefixed):

    selector {
        prop-abc: 3px !webkit-draft; /* browsers that implement a (pre-CR) 
webkit-draft-compatible prop-abc will recognize this */
        prop-abc: 3px 3px 0px 0px; /* browsers that implement a 
CR-compatible prop-abc will recognize this */
    }

vs

    selector {
        prop-cde: 3px; /* browsers that implement a CR-compatible prop-cde 
will recognize this */
        prop-cde: 3px 3px 0px 0px !webkit-draft; /* browsers that implement 
a (post-CR) webkit-draft-compatible prop-cde will recognize this */
    }



@@ If webkit decides to update his draft, he can decide to introduce 
!webkit-draft-2 and introduce a new syntax without breaking content relying 
on the !webkit-draft. A browser can implement more than one draft for a 
property, which is good to allow developers to compare them.



@@ If Google and Apple (which currently share the webkit prefix) have 
different drafts, they can simply have their own draft names (!apple-draft 
vs !google-draft). We can also, why not, give names based on the editor of 
the spec (!tab-draft or !daniel-draft) or on its version (!2012-03-draft). 
The name of the draft doesn't matter.



@@ We can use one declaration for multiple drafts if we know they are 
compatible for the value we give. This is a huge gain for authors.

    selector {
        property: value1 !webkit-draft;
        property: value2 !webkit-draft-2 !ms-draft;
    }

vs

    selector {

        -webkit-property: value1;

        -webkit-property: value2; /* praise that value2 isn't a valid value 
for first draft */
        -ms-property: value2;

        -moz-property: value2; /* if mozilla add support for the ms draft in 
the future */
        -o-property: value2; /* if opera add support for the ms draft in the 
future */

        property: value2; /* if a browser drop support for prefixed version 
before I update the website */

    }

/* and what about -khtml- ? */




This solution has probably disadvantages, too. But I think it has more 
advantages and less disadvantages than vendor prefixes. What do you think of 
it?

Kindly regards,
François

Received on Sunday, 29 April 2012 22:45:52 UTC