Re: Vendor-prefixes: an idea

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.

~TJ

Received on Monday, 7 May 2012 14:55:30 UTC