Re: Vendor-prefixes: an idea

(comments inline)

> From: Tab Atkins Jr.
> Subject: Re: Vendor-prefixes: an idea

Happy to see my proposal did please you. It has indeed advantages over the 
current vendor-prefix situation, but the most difficult part is, like often, 
overcoming the metastability. Support coming from people inside Google is 
already a good step.

Also, not having a real prefix written inside the property name makes 
unprefixing seems a lower barrier than it is now. It may be great, since it 
seems the working group is advancing toward a simpler and shorter path to 
unprefixing.


> On Mon, May 7, 2012 at 7:08 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> > 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;
>
> That's not strictly necessary, but it might be necessary given current
> parser designs.  (If your tokenizer and parser are separate passes, as
> soon as the parser sees the property name it can read from the end of
> the tokens comprising the property value to look for the vendor-bang,
> and then parse the remaining tokens only if it finds the right
> vendor-bang.)
>
>
> > 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.
>
> True.  We could potentially prefix them with *any* symbol that
> currently always tokenizes as a delimiter.  There's a lot of them.

Not as many as we would like, however.


> > 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.
>
> Shane mentioned this, but I'm not sure I agree.  While the property is
> prefixed, "implementing someone else's prefix" means actively checking
> for the other vendor's vendor-bang alongside your own, and considering
> the property valid if you find either.  However, I can see how it
> might feel like a lesser transgression to some people, particularly
> since "unprefixing" just means that you stop checking for vendor-bangs
> entirely.

I really love your interpretation. I didn't think like that myself when I 
originally proposed this idea, but reading your last paragraph made me think 
I should have found it myself, because this is really a nice way to see the 
whole thing. When the property goes "unprefixed", we simply start to ignore 
vendor tokens. It completely make sense.

Received on Monday, 7 May 2012 20:15:40 UTC