Re: Vendor-prefixes: an idea

Hi,

It is refreshing to see new approaches to solve this problem, but I am  
afraid your proposal wouldn't work.

Early implementations have no more documentation that a blog post  
somewhere. Even when that's not the case, whatever documentation exists  
often leaves significant part of the behavior undefined. Would two  
implementation qualify for the same !keyword if they behave the same on  
the parts that are explicitly documented (however small these are), but  
have big differences on the parts that are not? How much deviation from  
the documented behavior do you allow, before expecting an implementation  
to use a different !keyword?

If we don't document clearly the differences between the various !keyword  
variants, how are authors expected to know which of the several  
alternatives they should pick?

So, overall, I think is hard for browser vendors to do, and hard for  
authors to understand. That's enough for me to reject the idea, even if it  
could have interesting properties if it somehow were to be done right,  
because I don't expect it to be done right.

  - Florian


On Mon, 30 Apr 2012 00:45:32 +0200, François REMY  
<fremycompany_pub@yahoo.fr> wrote:

> 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 Wednesday, 2 May 2012 13:33:46 UTC