W3C home > Mailing lists > Public > www-style@w3.org > November 2011

RE: Unprefixing CSS properties

From: Sylvain Galineau <sylvaing@microsoft.com>
Date: Fri, 18 Nov 2011 04:31:11 +0000
To: "robert@ocallahan.org" <robert@ocallahan.org>
CC: "www-style@w3.org" <www-style@w3.org>
Message-ID: <3C4041FF83E1E04A986B6DC50F017829033896BC@TK5EX14MBXC296.redmond.corp.microsoft.com>
Whatever folks think of Henri’s conclusions, I think his provocative post was valuable as it reframed an old problem in a way that prodded new thinking. I thank him for that. 

While the ‘system’ we have derives from positive goals and makes a great deal of sense (to me at least) on the proverbial paper, there is no shortage of evidence it doesn’t always work as intended in practice. Arguing authors shouldn’t do X or Y misses the point when they are actively and objectively doing X *and* Y, day in and day out; and have done so for years. Many of the more knowledgeable authors are even actively engaged in routing around what they should be doing by building, advocating and/or deploying frameworks and preprocessors to avoid prefix pain!...When they're not on stage, in blogs or magazines advocating best practices that conflict with the 'system' e.g. 'copy/paste an unprefixed version of the prefixed property for future-proofing' which completely flies in the face of decoupling standards from implementation by coupling content with the most recent implementations.

However positive the goals of the current versioning scheme - and, again, I think they mean well - there is some evidence it does not work as intended even when authors understand its rules.
 
So while we have a fine theory of what authors should be doing, reality will probably win the argument regardless of how long we keep denying it and convincing ourselves of our users' irresponsibility. The current system also has a real cost for browser makers, tool vendors and authors. Asking whether the cost is worth the benefits - and whom any given proposal benefits - is both fair and healthy imo. It is also fair to submit any new proposal to the same degree of scrutiny we're applying to the existing arrangement.  

This being said, I wonder how much of this excellent discussion relates to actual harm vs. future *risk* extrapolated from relatively recent issues. As Tab points out, some of the incidents that may have triggered Henri's post are both recent and well-known e.g. gradient changes, Animation modules behind feedback and implementations etc. 

So I'd love to hear more about specific examples and supporting data. I am sympathetic to the argument that a bad versioning scheme can hurt the web. Or that it has caused pain and may do so again. But however attractively principled the case for change may appear, I think it is reasonable to go from the general - 'prefixes hurt the web' - to the specific. Some examples have been brought up; more data would be helpful. It's a big web. CSS is not that small either.

Last, it's great to see Jon Rimmer here. I hope other authors join in as their feedback is critical in getting this right. 

From: rocallahan@gmail.com [mailto:rocallahan@gmail.com] On Behalf Of Robert O'Callahan
Sent: Tuesday, November 15, 2011 8:02 PM
To: www-style
Subject: Unprefixing CSS properties

Web authors have complained a lot about excessive need for vendor prefixing. Henri Sivonen has recently blogged about the damage prefixing can do to the Web --- see http://hsivonen.iki.fi/vendor-prefixes/.


One observation is that when browser vendors already agree closely on the syntax and semantics of a property, and when Web authors routinely use the same property value for multiple engines' prefixed properties and the unprefixed property, in public Web content, vendor prefixes are providing negligible benefit and incur considerable costs --- or outright harm. I think we can improve the situation in the short term with relatively low risk by identifying properties whose specs are not yet in CR, but where the spec is considered stable (but for whatever reason not ready to enter CR, perhaps because it contains other properties that aren't stable), and agreeing to encourage unprefixed implementations of those properties. Naturally we still want implementations to be reasonably conformant before shipping unprefixed.

We had a meeting about this with some Mozilla developers today and came up with a proposed list of properties/features which we think are eligible for unprefixing:

2D Transforms: all properties
3D Transforms: all properties
Transitions: all properties
Animations: all properties (responses to feedback urgently need to be added to the spec, and that should probably happen first)
Conditional: nested @-rules (probably no-one would have prefixed this anyway)
Images: image() value, 'object-*', 'image-*'
Text: 'tab-size', 'hyphens', 'text-align-last', 'text-decoration-*'
Values: a subset of calc() (the intersection of what IE9 and Gecko implement), the new units
Selectors 4: :matches, :any-link, :nth-match, :nth-last-match, :column, :nth-column, :nth-last-column

Any objections? :-)

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us." [1 John 1:8-10]
Received on Friday, 18 November 2011 04:31:46 GMT

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