In Defense of Vendor-Specific CSS Prefixes
Sitepoint.com has been asking recently, “Should CSS vendor prefixes be abolished?” The poll has been running on their front page for the past few days and as of the writing of this post 51% of respondents have said “Yes” versus 22% “No”.
I’m kind of surprised actually. Likely the majority of respondents are web developers who would rather have the simplicity of typing in a single CSS declaration than 3 or 4 different ones (one for webkit, one for moz, one for IE8, and one for IE<8). For however tempting of a world that would be with all CSS implementations unified I don’t think it’s going to happen. Furthermore, if there was anything to learn from XHTML isn’t that theoretical standards don’t always translate into real world improvements.
An advantage of vendor-specific CSS prefixes is that it allows an HTML rendering engine vendor to experiment with a style implementation without breaking the implementations other browsers provide. Roll back the clock 8 years and this was a pretty big deal.
Consider, for example, HTML Engine “A” decides to implement an experimental CSS prefix “tween-animation”. It allows a developer to implement simple tween animations using CSS…
.heading { position: absolute; tween-animation: 10px, 10px, 50px, 50px; }
Mind you this is all hypothetical. So engine “A” implements this and you start using it on your site. Then later HTML Engine “B” also decides to do an implementation, but they decide to implement it differently. Now what? Your .heading tween-animation which works in Engine “A” now does weird stuff in Engine “B” except you have no way to specify that it’s only for Engine “A”.
Bam. That’s where vendor prefixes come in. Not only does it allow for new CSS experimentations but it does so in a way that won’t break in the future.
There are many other good reasons to maintain vendor-specific CSS prefixes. The discussion happening on the Sitepoint blog is a good place to start if you’re interested in more.
