Re: Vendor-prefixes: an idea

This is, indeed, a valid concern.

However, I don't think browsers should implement each other DVMs (draft 
value modifiers) if they don't feel strongly confident of doing so: it's not 
compulsory. When a property is in such an experimental stage that two 
implementations of the property can't be made compatible, the current model 
will continue to be used (ie: "!webkit-wd" for Safari's webkit, "!ms-wd" for 
Trident, "!moz-wd" for Gecko...). At that point, it's up to authors to 
include one or more DVM based on their findings, just like it's now.

But, even then, there are major wins compared to current situation since :
(1) you can specify more than one compatible draft in your declaration, 
instead of having one declaration per draft.
(2) after some time, vendors could decides to use aliases if usage proves 
the implementations to be compatible.
(3) after some more time, vendors could even agree on a common DVM.

At any point, if a vendor is confident enough to support the "vendor draft" 
of another browser, it's their responsability to take that decision, and 
it's their users that will face issues if the wrong decision is made. They 
are accountable, and accountability is key in taking cautious decisions. 
Opera didn't decide to support some -webkit- prefixed properties à la 
légère. BTW, in the current state of the things, Chrome and Safari share the 
same prefix and, while they sometimes use different implementations, they 
are often able to work out compat issues smoothly, even for poorly specced 
properties. Don't forget properties are not used from the day they are 
introduced. This time can be used to fix more pregnant issues.


A big advantage of this proposal is that browser vendors will finally be 
able to iterate their implementation. Right now, it took months to Mozilla 
and Chrome to accept the same input for css gradients, mainly because they 
were affraid that changing syntax would break old content. With a DVM, you 
can stay compatible with old content while supporting a new syntax under a 
new DVM. You can ship more than one syntax for developers to test out, too.


Anyway, I don't say this is the way to go. I just hope a solution will be 
found for this problem at some point; not as much as a developer than as an 
user: it's really frustrating to have to open sites in Chrome while I know 
the site/demo would work in my primary browser (IE10) if the right prefixes 
had been included.






-----Message d'origine----- 
From: Florian Rivoal
Sent: Wednesday, May 02, 2012 3:33 PM
To: www-style@w3.org
Subject: 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 14:52:05 UTC