In Defense of Vendor Prefixes
Published 13 years, 9 months past
…that having been the original working title for “Prefix or Posthack“, my latest article for A List Apart. (Sort of like Return of the Jedi had a working title of Blue Harvest.) In a fairly quick read, I make the case that vendor prefixes are not only good, they have the potential to be great and to deliver greater interoperability and advancement of CSS.
So far the reaction has been overwhelmingly positive, which frankly came as a bit of a surprise. The annoyance factor of prefixes is undeniable, and it’s been my experience that annoyance dramatically hardens opposition regardless of whether or not there are good reasons to oppose. I could flatter myself that the agreement is due to the Obvious Rightness of my argument, but I suspect it’s actually that I merely articulated what most people had already instinctively decided for themselves. Which isn’t a bad place to be.
Anyway, if you haven’t already, feel free to decide for yourself by reading the article — which, I feel like mentioning for no clear reason, is only the fourth piece I’ve ever written for ALA.
Comments (7)
The annoyance factor of prefixes is less than the annoyance factor of hacks ;)
Indeed, and I think that anyone “advanced” enough in CSS to be aware of vendor prefixes is most likely someone who also went through /* the pai\n of “\”}\”” various @hacks \*/.
The prefixes are intentional, its as simple as that. Which means we can make them what we want them to be.
It becomes a win-win for authors that want a way to “filter” for different browsers and their capabilities, and its a way for vendors that want to test something and see what works and get feedback.
“it’s actually that I merely articulated what most people had already instinctively decided for themselves.”
True for me. Glad someone with your standing brought it to the fore. I only hope implementors reach a consensus on best-practice for prefixes. Like any system, predictability and consistency are key.
Any predictions for how browsers can prefix CSS3 features that aren’t properties like -moz-border-radius? I’ve seen on css3.info that Firefox 4 will bring -moz-calc() which is cool, but I wonder how one would prefix, say, the new “rem” unit (http://www.w3.org/TR/css3-values/#relative).
To be honest, I sort of wish every property could have a vender specific prefix, not just the in progress ones.
Every now and then, for reasons you can’t figure, you need to get Webkit to have a different line height than other browsers, or Firefox needs a different width, or IE needs a different margin and you just wish you could:
p { line-height: 22px; -webkit-line-height: 24px; }
Honestly you could probably say the most random craziest thing and people would agree with you. Because people trust you. You are are the best of the best. A lot of people don’t think for themselves. You have a lot of influence on today’s standards and practices and people know it. Some follow blindly.
But, you are trusted for a reason. You’ve not yet lead us astray.