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

Re: Proposition to change the prefixing policy

From: Brad Kemper <brad.kemper@gmail.com>
Date: Wed, 9 May 2012 10:05:06 -0700
Message-Id: <96D7E97E-DE29-4D84-A92B-67F7FAEC9304@gmail.com>
Cc: "www-style@w3.org" <www-style@w3.org>
To: Allan Sandfeld Jensen <kde@carewolf.com>
On May 8, 2012, at 1:34 PM, Allan Sandfeld Jensen <kde@carewolf.com> wrote:
> At the risk of muddying the water. I would like make a slighly different 
> suggestion that takes offset in the current situation.
> 
> A vendor may implement prefixed or unprefixed properties at any time. 
> (Realistically speaking, who is going to stop them?) It is recommended they 
> implement the feature unprefixed when deemed stable. If both a prefixed and 
> unprefixed versions of a property are set and supported by the vendor, the 
> unprefixed should override the prefixed.

We have that already, if the author lists the unprefixed version last (which is best practice). 

Otherwise, if order doesn't matter, then this would make the cascade much more complicated, I would think. Using a prefix would be equivelent to also adding something like !less-important. The cascade can already become very messy when !important is thrown into the mix (I've used it to override style attributes, but then had to modify a whole set of rules to also include !important, in order to have them cascade correctly), so I don't like this idea.

> Other vendors may implement other vendors prefix (again, realistically 
> speaking this is inevitable), if they deem their product compatible enough, 
> but must always give prefererence to properties with their own prefix, and 
> unprefixed before other vendors.

So that would be like having an implied !even-less-important for other vendor's prefixes. 

> The override logic is going to complicate things a little

Ya think?

> At least for WebKit the overrides should not be too complicated, the only 
> issue is that vendor prefix is stripped during parsing,
> but if maintained, the 
> properties just need to be split into three groups applied in succesive order, 
> Supported foreign/obsolete vendor prefix, native vendor prefix and finally 
> unprefixed.

That would be three levels for each existing specificity when determining the cascade. In other words, you'd maybe subtract .1 from the cascade score for prefixed and subtract .2 for other vendor prefixed. Or something like that. 
Received on Thursday, 10 May 2012 06:06:12 GMT

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