All products featured on WIRED are independently selected by our editors. However, we may receive compensation from retailers and/or from purchases of products through these links.
Vendor-specific CSS prefixes have been popping up in all the shiny and fancy CSS 3 demos of late. Microsoft IE 9, Firefox and Safari have all been using them to show off their latest CSS tricks, and you've probably already formed an opinion about them.
Web purists scoff at prefixes, since they add to the amount of coding and testing required just to get something to show up consistently across browsers. Repetition and bloat aren't welcome in this camp. But those who live on the bleeding edge see them in a different light.
In his latest piece for A List Apart, noted CSS scholar Eric Meyer argues that vendor-specific prefixes should be welcomed, not reviled: "We ought to praise vendors for using prefixes, and indeed encourage them to continue," he writes.
Meyer's argument is simple. Coding a stack of prefixes into your CSS is not ideal, but it's better than the alternative of using inconsistent CSS hacks or having to sniff for user agents to serve up totally different styles to different browsers.
He also argues that, "prefixes should become a central part of the CSS standardization process... I believe that prefixes can actually accelerate the advancement and refinement of CSS."
And it makes sense. Consider the author working with some brand new CSS property. At this point in its young life, all of the browsers are implementing the property, but all are doing so differently. The author can use the property – with prefixes – and gain the utility of whatever magic that CSS property is supplying without having to worry about their pages breaking in such-and-such browser.
These temporary hacks dwindle over time, Meyer writes.
Definitely check out the whole article. It draws some interesting conclusions. Meanwhile, how do you feel about prefixing in CSS? Does it bother you, or do you agree with Eric that the practice will only make everything more interoperable in the future?
See Also: