CSS Vendor Prefixes

What Are They and Why You Should Use Them

Mac Browser Galore
richoz/Flikr/CC BY 2.0

CSS vendor prefixes, also sometime known as or CSS browser prefixes, are a way for browser makers to add support for new CSS features before those features are fully supported in all browsers. This may be done during a sort of testing and experimentation period where the browser manufacturer is determining exactly how these new CSS features will be implemented. These prefixes became very popular with the rise of CSS3 a few years ago.


When CCS3 was first being introduced, a number of excited properties began to hit different browsers at different times. For example, the webkit-powered browsers (Safari and Chrome) were the first ones to introduce some of the animation-style properties like transform and transition. By using vendor prefixed properties, web designers were able to use those new features in their work and have them seen on the browsers that supported them right away, instead of having to wait for every other browser manufacturer to catch up!

So from the perspective of a front-end web developer, browser prefixes are used to add new CSS features onto a site while  having comfort knowing that the browsers will support those styles. This can be especially helpful when different browser manufacturers implement properties in slightly different ways or with a different syntax.

The CSS browser prefixes that you can use (each of which is specific to a different browser) are:

  • Android: -webkit-
  • Chrome: -webkit-
  • Firefox: -moz-
  • Internet Explorer: -ms-
  • iOS: -webkit-
  • Opera: -o-
  • Safari: -webkit-

In most cases, to use a brand new CSS style property, you take the standard CSS property and add the prefix for each browser. The prefixed versions would always comes first (in any order you prefer) while the normal CSS property will come last.

For example, if you want to add a CSS3 transition to your document, you would use the transition property as shown below:

-webkit-transition: all 4s ease;
-moz-transition: all 4s ease;
-ms-transition: all 4s ease;
-o-transition: all 4s ease;
transition: all 4s ease;

Note: Remember, some browsers have a different syntax for certain properties than others do, so don’t assume that the browser-prefixed version of a property is exactly the same as the standard property. For example, to create a CSS gradient, you use the linear-gradient property. Firefox, Opera, and modern versions of Chrome and Safari use that property with the appropriate prefix while early versions of Chrome and Safari use the prefixed property -webkit-gradient. Also, Firefox uses different values than the standard ones.

The reason that you always end your declaration with the normal, non-prefixed version of the CSS property is so that when a browser does support the rule, it will use that one.  Remember how CSS is read.  The later rules take precedence over earlier ones of the specificity is the same, so a browser would read the vendor version of a rule and use that if it does not support the normal one, but once it does, it will override the vendor version with the actual CSS rule.

Vendor Prefixes are Not a Hack

When vendor prefixes were first introduced, many web professionals wondered if they were a hack or a shift back to the dark days of forking a website's code to support different browsers (remember those "This site is best view in IE" messages). CSS vendors prefixes are not hacks, however, and you should have no reservations about using them in your work.

A CSS hack exploits flaws in the implementation of another element or property in order to get another property to work correctly.For example, the box model hack exploited flaws in the parsing of the voice-family property or in how browsers parse back-slashes (\). But these hacks were used to fix the problem of the difference between how Internet Explorer 5.5 handled the box model and how Netscape interpreted it, and have nothing to do with the voice family style.

Thankfully these two outdated browsers are ones we do not have concerns ourselves with these days (for those of you who were not in the industry at this time, be thankful!  They are dark and confusing times, indeed!).

A vendor prefix isn’t a hack because it allows the specification to set up rules for how a property might be implemented, while at the same time allowing browser makers to implement a property in a different way without breaking everything else. Furthermore, these prefixes are working with CSS properties that will eventually be a part of the specification. We are simply adding some code in order to get access to the property early. This is another reason why you end the CSS rule with the normal, non-prefixed property. That way you can drop the prefixed versions once full browser support is achieved. 

Want to know what the browser support for a certain feature is? The website CanIUse.com is a wonderful resource for gathering this information and letting you know which browsers, and which versions of those browsers, currently support a feature.


Vendor Prefixes are Annoying But Temporary

Yes, might feel annoying and repetitive to have to write the properties 2–5 times to get it to work in all browsers, but it’s a temporary situation. For example, just a few years ago, to set a rounded corner on a box you had to write:

-moz-border-radius: 10px 5px;
-webkit-border-top-left-radius: 10px;
-webkit-border-top-right-radius: 5px;
-webkit-border-bottom-right-radius: 10px;
-webkit-border-bottom-left-radius: 5px;
border-radius: 10px 5px;

But now that browsers have come to fully support this feature, you really only need the standardized version:

border-radius: 10px 5px;

Chrome has supported the CSS3 property since version 5.0, Firefox added it in version 4.0, Safari added it in 5.0, Opera in 10.5, iOS in 4.0, and Android in 2.1. Even Internet Explorer 9 supports it without a prefix (and IE 8 and lower didn’t support it with or without prefixes).

Remember that browsers are always going to be changing and creative approaches to supporting older browsers will be required unless you’re planning on building web pages that are years behind the most modern methods.

In the end, writing browser prefixes is much easier than finding and exploiting errors that will most likely be fixed in a future version, requiring that you find another error to exploit and so on.

Original article by Jennifer Krynin. Edited by Jeremy Girard on 4/3/17