RE: Unprefixing CSS properties

And one more thing: I don't really care what any browser vendor's
 internal discussion concluded. If you want to change how we handle
versioning, it's no different than changing any other CSS feature: 
you're going to have to share those parts of your discussion that 
are relevant to achieving the outcome you desire in the open. Specifically, 
you probably don't just agree with Henri because his blog post is  
articulate, thoughtful and well argued. You considered other facts 
and data points to come to a decision. If so, please help the community
by sharing them. 

This is a responsibility we all share. Thank you.

> -----Original Message-----
> From: Sylvain Galineau []
> Sent: Thursday, November 17, 2011 8:31 PM
> To:
> Cc:
> Subject: RE: Unprefixing CSS properties
> 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: [] 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
> 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 05:06:38 UTC