Re: Vendor-prefixes: an idea

On May 7, 2012, at 7:54 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Mon, Apr 30, 2012 at 12:45 AM, François REMY
> <fremycompany_pub@yahoo.fr> wrote:
>> 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;
>>   }
> 
> Shane convinced me to give this another look, and after some thought,
> I think I can *really* be behind this.
> 
> Naively, this is isomorphic to the current vendor prefixes.  This
> initially caused me to dismiss it; like the "-draft1-" prefix ideas, I
> thought it didn't offer anything actually new, so the problems weren't
> really solved.
> 
> This isn't true, though!  This proposal actually has some *really*
> nice additional properties that make this *significantly* better than
> the current prefixes, and explicitly solves some of our problems.
> 
> In particular, the "Oh no, we took too long to unprefix, and now the
> prefixed property must be supported forever for web compatibility"
> problem completely goes away.  When the spec hits "unprefixable"
> state, you just *stop requiring your vendor-bang*.  If authors keep
> using your vendor-bang, that's fine, because extra vendor-bangs are
> simply ignored.  New browsers entering the market never have to pay
> attention to vendor-bangs for mature properties.
> 
> Since a property can accept multiple vendor-bangs, this is obviously
> shorter than the existing practice of duplicating properties multiple
> times.
> 
> If a property changes syntax between first implementation and CR,
> that's okay - you can just put another line afterwards without the
> vendor-bang, like:
> 
> foo: bar !-vendor;
> foo: baz;
> 
> In old browsers, the second declaration is invalid because it lacks
> the vendor-bang, so you use the first.  In new browsers, the first
> declaration is invalid because the 'bar' keyword isn't allowed
> anymore, so you use the second.  The only failure-mode is if some of
> the old syntax overlaps the new syntax, but has a different meaning
> (like what linear-gradients did with <angle>s).  The simple solution
> is "don't do that".  If you absolutely *must* do that, just change the
> property name.
> 
> One weakness I can find is that it seems harder to use this for
> functions and at-keywords, but this can be fixed.  We could define
> that at-keywords allow bangs immediately before the block or
> semicolon, and functions allow bangs just before the close-paren.  The
> existing !important would just be a syntax error, but vendor-bangs
> would be ignored.
> 
> Property-name squatting is now a *lesser* problem, but not completely
> gone.  It's a *different* problem than it is in the other "never
> prefix" arguments, though.  Now, the only problem is that if you
> decide late in the game that you want to change the property name, you
> create the possibility of "oh no, the web depends on the old name for
> compat", exactly like how current prefixes work.  This is better than
> current prefixes, because it's exactly as bad, but much less common.
> It should also encourage us to do name changes early, because this is
> now a problem that happens *only* with late name changes, rather than
> by default.
> 
> I'm going to strongly argue for vendor-bangs at the meeting this week.

One other issue with vendor-bang is that it makes it hard on parsing when the !'d version has a distinct syntax from the official, as you have to parse the whole property before you know how to parse it. This is a solvable problem in principle, but it really makes life easier to have a potential syntax switch come at the beginning rather than at the end, for example:

foo: !-vendor bar;

Another downside is that the !important syntax is some of the ugliest and most confusing syntax in CSS ("not important means important?") and it would be a shame to propagate it.

As far as upsides upsides, this proposal makes it seem a little less psychologically icky to implement someone else's prefix, since you're "ignoring" it rather than "supporting". But the effect is the same. It's also less verbose for authors to support multiple vendors at one go. These are admittedly some real benefits.

Regards,
Maciej

Received on Monday, 7 May 2012 17:09:08 UTC