W3C home > Mailing lists > Public > www-style@w3.org > May 2012

Re: Vendor-prefixes: an idea

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 8 May 2012 16:55:41 +0200
Message-ID: <CAAWBYDCCRx5DoBJkNuz8CESfRmV92pa-uQgLHXSyWJs5zWydJg@mail.gmail.com>
To: Jonathan Snook <jonathan@snook.ca>
Cc: François REMY <fremycompany_pub@yahoo.fr>, CSS 3 W3C Group <www-style@w3.org>
On Tue, May 8, 2012 at 4:50 PM, Jonathan Snook <jonathan@snook.ca> wrote:
> I'm trying to understand how this is more beneficial to web developers over the existing prefix approach.
>
> As I understand it,
>
> -moz-border-radius: 3px;
> -webkit-border-radius: 3px;
> -o-border-radius: 3px;
> border-radius:3px;
>
> would simply be replaced with:
>
> border-radius: 3px !moz-draft;
> border-radius: 3px !webkit-draft;
> border-radius: 3px !o-draft;
> border-radius: 3px;

Nope, it would be:

border-radius: 3px !moz-draft !webkit-draft !o-draft;

That works in prefixed-Firefox, prefixed-Webkit, prefixed-Opera, and
unprefixed-everyone.  You always ignore vendor-bangs you don't
understand, and once you unprefix a property, you ignore your own
vendor-bang as well.


> While visually more appealing, it doesn't seem to solve the problem that...
>
> * prefixes/suffixes aren't dropped
> * web developers will use an implementation before it's finalized
> * web developers will target a specific browser without providing fallbacks to other browsers
>
> If I misunderstood and that future implementations should actually ignore !suffixes such that we might see implementations like:
>
> border-radius: 3px !moz !webkit;
>
> …and simply have the suffixes ignored in final implementations, then I see some positives.
>
> * implementations that don't change between draft and rec will work without requiring web devs to update implementations.
> * implementation changes can be localized with separate declarations (like prefixes are now).
>
> Could you clarify the intent here?

Hopefully I've done so now.  ^_^

~TJ
Received on Tuesday, 8 May 2012 14:56:39 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:53 GMT