Re: Proposition to change the prefixing policy

On Friday 04 May 2012, Florian Rivoal wrote:
> ==== Proposal ====
> 
> When a browser vendor implements a new css feature, it should support it,
>  from day 1, both prefixed and unprefixed, the two being aliased. If a
> style sheet contains both prefixed and unprefixed, the last one wins,
> according to the cascade.
> 
> Authors should write their style sheets using the unprefixed property,
> and only add a prefixed version of the property (below the unprefixed
> one) if they discover a bug or inconsistency that they need to work
> around in a particular browser.
> 
> If a large amount of content accumulates using the a particular vendor
> prefix to work around an issue with the early implementation in that
> browser, the vendor could decide to freeze the behavior of the prefixed
> property while continuing to improve the unprefixed one.
> 
This doesn't solve the status quo, and I really would prefer the unprefixed 
properties to deprecate vendor prefixed version, at least in practice. Also 
which order should authors declare their properties in? I think today they 
usually declare the prefixed ones first, and the unprefixed last.

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.

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. This means that if an author only uses one vendors prefixes, other vendor 
may use that declaration. If an author declares both unprefixed properties and 
prefixed, then vendors should use the unprefixed if they claim support for the 
feature. If an author declares multiple vendor prefixes, vendors should use 
their respective prefixed versions, but may use other vendors if their own is 
not declared.

The override logic is going to complicate things a little but is necessary to 
avoid a foreign yet supported vendor prefix from override earlier real vendor 
specific settings. And the unprefixed should always override the others, since 
we otherwise end up in the situation where the unprefixed version has a lot 
bugs because all the large browser has specific different versions. 

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.

I hope that makes sense, so why is the dumbest thing ever suggested?
`Allan

Received on Tuesday, 8 May 2012 20:35:22 UTC