On vendor prefixes

  Wynn Netherland • February 09, 2012

There has been much written lately on vendor prefixes. While some have called for abolition altogether, ironically enough the CSSWG itself is mulling over making -webkit part of the spec. It’s enough to make you wonder if the web punditry ever build anything with the languages and tools they help shape.

# Why we have vendor prefixes

Vendor prefixes are a way for browsers to support features before the spec for a feature is finalized. Early on, implementations of border-radius and gradient rules differed between Firefox and WebKit browsers because the standards had not been established. Without the -webkit and -moz vendor prefixes, it would be impossible for developers to use these features because a single syntax would cause breakage in the other browsers. Adoption would have been much slower without the freedom vendor prefixes provide. Thus, they are a necessary evil.

# Vendor prefixes must be unique per rendering engine

That the CSSWG is even considering supporting -webkit for non WebKit browsers is beyond me. Remy Sharp says it well:

This is pandora’s box, no matter how you look at it. Once you add a single -webkit vendor prefix the expectation of the developer changes. If you can use a -webkit prefix in Firefox for gradients (for transforms), why can’t I use it for other things like CSS masks. And then other things.

If developers are lazy today, by adding -webkit prefixes to other browsers it’ll allow us to be even lazier, and by adding -webkit to the spec, the CSS working group will have set the presidence that we can, as developers, put any prefixes property in the other browsers.

If you’re going to put -webkit on everything, then the browser wars are over and we’re not much better off than the days of style="FILTER:progid:DXImageTransform.Microsoft.MotionBlur (strength=9, direction=90)".

# Better tooling to deal with vendor prefixes

The recent actions of the CSSWG aside, I normally don’t worry about vendor prefixes too much. I let my tools handle them for me. The Compass CSS3 module has long made dealing with prefix soup a snap.

.radial-gradient {
  @include background-image(radial-gradient(45px 45px, aqua 10px, #1e90ff 30px)); }

Which will yield the following CSS:

.radial-gradient {
  background-image: -webkit-gradient(radial, 45px 45px, 0, 45px 45px, 30, color-stop(33.333%, #00ffff), color-stop(100%, #1e90ff));
  background-image: -webkit-radial-gradient(45px 45px, #00ffff 10px, #1e90ff 30px);
  background-image: -moz-radial-gradient(45px 45px, #00ffff 10px, #1e90ff 30px);
  background-image: -o-radial-gradient(45px 45px, #00ffff 10px, #1e90ff 30px);
  background-image: -ms-radial-gradient(45px 45px, #00ffff 10px, #1e90ff 30px);
  background-image: radial-gradient(45px 45px, #00ffff 10px, #1e90ff 30px);

I can choose to support as many or as few browsers as I want just by setting some configuration variables in my stylesheet.

Compass isn’t the only option of course. Prefixr, Nib, and others abound. Find what works for your workflow and stop sweating it. Use a standard syntax and let your tools figure out the details.