By Craig Buckler

Should We Abolish CSS Vendor Prefixes?

By Craig Buckler

Prefixes are the vendor-specific names tagged to the start of CSS properties. For example, you require the following code to rotate an element by 10°:

-moz-transform: rotate(10deg);		/* Firefox 3.5+ */
-o-transform: rotate(10deg);		/* Opera 10.5+ */
-webkit-transform: rotate(10deg);	/* Chrome and Safari3.1+ */
-ms-transform: rotate(10deg);		/* IE9 */
transform: rotate(10deg);

(You could optionally use Microsoft’s DXImageTransform.Microsoft.Matrix filter to support IE6 and IE7).

Why do we need prefixes?

First, you should understand that web standards are not dictated by the W3C. The Consortium is not responsible for innovation — that’s left to browser vendors.

For example, assume Opera invented a new CSS property named ‘polygon’ which magically transformed a rectangular element into a standard shape, e.g.

polygon: 6; /* a hexagon */

Now consider that, by pure chance, Mozilla were also working on their own implementation of the polygon property. However, instead of a number of sides, Mozilla preferred a named value:

polygon: hexagon;

It leaves web developers with a serious headache. If they want to use the polygon property, it’s impossible to support both browsers at the same time. A numeric value fails in Firefox and a named value fails in Opera.

Vendor prefixes solve the problem, e.g.

-o-polygon: 6; /* Opera support */
-moz-polygon: hexagon; /* Firefox support */

Microsoft and/or the webkit team could create their own polygon implementation. If two or more vendors agree, the polygon property will ultimately become part of the W3C CSS specification.

The compatibility issue is highlighted by the relatively new background gradient syntax. The webkit team have implemented a fairly complex but versatile solution. Mozilla’s implementation is closer to the draft W3C specification — but that’s still a draft document and could change:

background-image: -webkit-gradient(linear,left top,left bottom,color-stop(0,#000000),color-stop(1,#ffffff));
background-image: -moz-linear-gradient(top,#000000,#ffffff);

Are prefixes still necessary?

The rotation example above highlights several issues:

  • the code is verbose
  • it’s too easy to forget a prefix, and
  • every vendor supports the same syntax.

Prefixes are a solution to a problem that rarely occurs. Browser vendors do not work in isolation: Microsoft, Apple, Mozilla, Google and Opera are all W3C members and none would implement their own feature without referring to what others were doing.

Consider the -webkit-transition properties. The webkit team are leading CSS transition development and others are following. So why is the prefix necessary? Vendors are unlikely to deviate from webkit’s implementation. Serious technical problems or flawed ideas are likely to be fixed by the webkit team first.

But it’s not just newer properties. Border-radius has been available for several years and every vendor implements the same syntax. Yet, to ensure good browser compatibility, developers still need to use:

-moz-border-radius: 10px;
-webkit-border-radius: 10px;
border-radius: 10px;

Vendors have their own opinions about when a property is “standard” enough. It will be many years before the vendor-specific border-radius properties die.

CSS guru Peter-Paul Koch has been particularly scathing about prefixes on his QuirksMode blog:

It’s time to abolish all vendor prefixes. They’ve become solutions for which there is no problem, and they are actively harming web standards.

Should CSS prefixes be abolished?

Are vendor prefixes still required in an age of increased browser cooperation? I doubt any developer wants to use prefixes, but are they a necessary evil? Would it be better if vendors added properties without prefixes, but made it clear they were experimental and not (yet) a standard?

That’s the topic for this week’s SitePoint poll. Please cast your vote and leave your comments below…

  • Hardy


  • tjameswhite

    No, vendor prefixes are very much needed. Take your border-radius property — it was *not* implemented the same by all browsers.
    -moz-border-radius: 10px 20px;
    -webkit-border-radius: 10px 20px;
    produced different results.
    Also, the following (at first) produced different results:
    -moz-border-radius: 10px / 20px;
    -webkit-border-radius: 10px / 20px
    Plus you had -moz-border-radius-topleft vs -webkit-border-top-left-radius
    Yes, the vendors can work together and sort out the syntax, but until then, we need prefixes to prevent rendering errors once the spec is finalized.

    • It *was* different, but that’s no longer the case. And it was implemented several years ago — would the same thing happen today now all the vendors are best friends?!

      • Ben Truyman

        No, it’s still different. You even provided an example with gradients. Prefixes namespace unapproved specs. Just because the syntax of many of these properties are consistent across browsers today, doesn’t mean that will necessarily be the case tomorrow.

        “Vendors are unlikely to deviate from webkit’s implementation.”

        I don’t want to deal with the “likeliness” other vendors are going to deviate from another’s implementation. Why chance it (see Murphy’s Law)? Unspec’d CSS functionality does NOT belong in the same namespace as spec’d/supported functionality.

        This has been discussed in depth over at PPKs site already. Not to mention most of the comments on his post disagreed with his assertions.

      • fn64

        among those ‘best friends’ there always will be ones ‘better’ than others ;)

    • Andrew

      If they are abolished, what is to happen about maintaining backward compatibility?

      Surely soon enough there won’t be a need for prefixes and one gradient CSS3 standard will be fully accepted and implemented by all vendors (hopefully ‘correctly’). But what if a site has -moz-linear-gradient but no official one?

      Clearly it would be in Mozilla’s best interest to keep -moz-linear-gradient working for a very long time as a lot of sites are using it at this point. And same for WebKit (-webkit-gradient). Newer versions of Firefox should listen to the official one if it is there, and the old if it’s not, and maybe even listen to -webkit-gradient if it’s there but not the new one nor -moz-*-gradient.

      Honestly it wouldn’t be that bad if there was simply -property (meaning dash prefix) used for vendor-specific implementations and others could adapt. Similar to how OpenGL extensions get proposed and eventually accepted minus the vendor name being present. nVidia always puts some neat stuff developers may use and ATI the same; eventually some of these features become standard in later versions of OpenGL.

  • They call me… Tim

    You’re a few months late to the conversation. Many people responded to PPK’s initial blog post, and he himself has written a follow-up:
    The short answer is “no”, you can’t abolish vendor prefixes. They are a solution to a problem, and without the prefixes the problem would come back.

  • Michael

    Vendor-specific prefixes are a great way for browsers to get bleeding-edge features into the hands of developers.

    If you’re not happy with the implementation of them, don’t use them — no one’s forcing anyone to use vendor-specific prefixes. For those that would like to try them out or add a little extra style to their page(s) they’re there.

    What’s the problem? I don’t like beets, but I’d never say “get rid of beets” rather I’d probably just not grab them from the salad bar.

  • John

    I defer to the great Eric Meyer:
    Some browser inconsistencies Eric points out:
    “Mozilla and WebKit browsers render box-shadow blurring very differently, and neither fully conforms to the specification. As I write this paragraph, a lengthy and heated debate is raging on the www-style mailing list.”
    “Mozilla and WebKit browsers both support gradients, but they use radically different syntaxes to achieve the same basic result.”

  • MUW

    Nowadays its not really the case that browser vendors have a property which really deviates in principle from other peoples implementation. Maybe small deviations, but nothing big at all.

    Keeping that in mind, vendor prefixes as unnecessary code, and many people just run with the vendor prefix code of the first implementor, and never bother to add the vendor prefix code of other browsers which may also support the same feature later on.

    It really ends up hurting the web more than bettering it.

  • Wolf_22

    Yes, they should be abolished. There may be more reasons, but off the top of my head…

    A.) The standards pot is still melting…

    B.) It’s free marketing.

    • Actually, both of these reasons seem to point to a “no” answer… :-)

      About the topic, I defer to the great Eric Meyer, too, as John did before me.

  • fn64

    i think it’s too early to abandon vendor prefixes. css3 spec is still immature and needs a lot of work. new properties implementations vary from browser to browser. and browsers’ update cycle also vary greatly.
    thought you can use ‘border-radius’ for webkit, remember that current gecko still needs prefix, and current opera implementation is buggy.

    yes, vendor prefixes are redundant and ugly, but remember, all those new features are still experimental – use them with proper care

  • goldfidget

    IMO it’s a non-issue. Vendors can get their technology out there for us to see, but we shouldn’t be using prefixed properties in anger.

    I’ll occasionally drop a few into a CMS back end where it doesn’t matter so much if someone doesn’t see the dropshadow correctly, but I’d never use a non-finalised spec on a client site that someone was paying for. Why drop a load of maintenance problems on someone. Cross browser compatibility still matters and IE6 is still out there.

  • bemo56

    The only thing I hate more than vendor prefixes, is css hacks… The old “*” before the html element hack for early IE browsers drives me crazy.

    While most of the implementations of a particular property are similar, there are enough properties that are different for vendor tags to be needed. I would use vender tags any day, over relying on a particular bug being present in only one browser.

  • jonthomas83

    Prefixes should be abolished, and there should be a common (non-prefuixed) property that should be adopted by all browsers like all other CSS rules. Don’t see why or how anyone can argue against that really! It’s common sense and better for everyone surely?

    • cornbread

      Agree with Jon here, properties should not be mixed with selectors. Specific calls to browsers should be done at the selector level so different values can be set depending on browser implementation.

  • heggaton

    They should be kept until the W3C standardises them.

    Once a specification has been defined, the vendor prefix is deprecated and everyone starts using the standard.

    • The specifications have been defined, abet in draft. In some cases, vendors consider that to be good enough — after all, we’re unlikely to see major changes to border-radius. But Mozilla, for example, still doesn’t support it without the ‘-moz’ prefix.

      Perhaps what’s needed is a series of smaller CSS specifications rather than an all-encompassing monolithic document which takes many years to become a W3C Recommendation?

      • Rob Crowther

        We already have a series of smaller specifications, that’s the major change in structure between the monolithic CSS2.1 and the multiple standards which comprise CSS3.

      • They’re still huge specifications, though!

  • Keiron Lowe

    The world would be a much better place if they browser creators stopped thinking about their own browser and all worked together to get every browser as best they can, that way no one has to suffer with stupid browser incompatibilities etc.

    • goldfidget

      Very true, but then how would any of them make any money? That’s not how capitalism works. Everyone does the best job they can, then the market decides.

      • Not that I think we can ditch vendor prefixes but that’s not how capitalism works either. Everyone does the best they can within the bounds of their industry’s regulations (ie: standards), then they brand the heck out of it and the consumer decides.

  • I’m sorry, but either you are playing devil’s advocate or you don’t understand how the standardisation process works. As mentioned above, PPK has already backed away from his original opinion, and Eric Meyer spells out exactly why vendor prefixes are required.

    In your article you provide two examples – border-radius and gradient – that prove exactly why vendor prefixes are required. To that list we can also add transform (there are differences in FFX & WebKit).

    border-radius is the best example; it was implemented differently between browsers until the spec was mature – now that it is, all browsers have removed the prefix (Firefox 4, IE9 will be the last). The prefixes are then kept in for backwards compatibility.

    They are absolutely required for the standardisation process to happen.

    • OK, so I am playing devil’s advocate a little, but I want to know what developers think of prefixes.

      On one hand, they prevent incompatibility issues. On the other, they’re a pain and we’ll probably be stuck with prefixes many years after a property becomes a standard. If the early poll results are anything to go by, the majority of developers don’t want them.

      Perhaps the main issue is that vendors have differing opinions to the maturity of a specification. Some vendors drop the prefix as soon as it’s in draft while others wait for the final recommendation. If border-radius was part of a mini-specification, it could be agreed, approved and adopted before the final CSS3 spec appears in 2073!

      • Whether developers want them or not, they are required. We developers don’t want to have to deal with legacy browsers either, but we have to. If you’re not comfortable with using vendor-specific properties, you can leave them out, it’s absolutely fine. There are workarounds to do all of this stuff, we’ve been doing it for years.

        The thing to remember is this: we don’t have to wait until a spec is final before we can use it. CSS2.1 isn’t a full recommendation yet, and we’ve been using it for a long, long time. CSS is mature when it’s implemented in at least two browsers in a standardised way and there are tests available to check compliance. The Backgrounds & Borders module is pretty much done, which is why all browsers are implementing it now, but the spec won’t be a recommendation for quite a few years yet.

        If a single non-prefixed property were implemented differently in two different browsers we’d have to resort to hacks again, and I’m sure nobody wants to revisit those days. All browser makers are now working in harmony in a way that makes standards the definitive goal, and even if that causes some short term inconvenience to developers (that is by their own choice), it’s still totally worth it. Even if the poll comes out 100% in favour of dropping vendor prefixes the browser makers won’t do it – and neither should they.

        As a side-note: The CSS3WG did release a snapshot of stable implementations in 2007 (; this was intended to be an annual event, but they never followed up on it.

  • Dan Blows

    I totally agree with not abolishing prefixes. Sure, it makes things harder in the short term, but we’re saving ourselves lots of headaches 10-15 years down from now.

    Removing prefixes and then requiring developers to ‘remember’ that those properties are still in beta is more difficult – the prefix tells you it’s in beta so there’s no need to remember.

  • Wolf_22

    In essence, is this overall debate (or argument) any different from the old headache-inducing discussions of IE6 compatibility?

    • Wolf_22

      (Sorry for the duel post, but the point being from my last comment that refining and revising [and removing] things like this from languages / scripting eventually pushes vendors to standardization.)

  • cowbrown

    An excerpt from Andy Clarke’s new book, Hardboiled Web Design talking about the use of CSS gradients in our designs and the difference between Webkit’s and Firefox’s (official W3C) implementation of the process…

    “It’s likely that future versions of WebKit will implement the W3C’s official gradient syntax. I’ll bet my badge on it. I’ll also wager that, to ensure backwards compatibility with the countless websites and applications already using its gradients, WebKit will continue to support the older syntax.
    Does writing gradient declarations twice take extra time? Yes — welcome to an imperfect world. Should that stop us from using CSS gradients? It should not. This is precisely the kind of situation that demonstrates the importance of vendor-specific prefixes and how they enable browser makers to perfect their implementations while we make creative use of the new properties.”

    Need we say anymore?

    Apart from that I’m astonished to see the way the poll is shaping up at the moment with almost 50% of people saying ‘Yes’, they should be abolished. Get a grip people!

  • Rob Crowther

    It’s statements like these two that lead me to believe you’ve not really spent any time investigating how the W3C standardisation process works:

    First, you should understand that web standards are not dictated by the W3C. The Consortium is not responsible for innovation — that’s left to browser vendors.

    Many of the people who are responsible for writing the standards are working for the browser vendors who are responsible for the innovation. There’s not two separate groups of people here, one doing innovating and one doing standardising.

    Consider the -webkit-transition properties. The webkit team are leading CSS transition development and others are following. So why is the prefix necessary? Vendors are unlikely to deviate from webkit’s implementation.

    Actually, yes, the final standard is likely to deviate from WebKit’s implementation. There has been extensive discussion of this on the www-style mailing list, particularly around whether we really need both CSS Transitions and CSS Animations.

    • The five main browser vendors are all W3C members. However, there is a widespread misconception that the W3C invents new standards for vendors to follow and specifications must be complete before the properties can be used. The W3C specifications follow browser implementation rather than the other way around.

      But your second point contradicts your first! Why would the final W3C standard deviate from webkit’s implementation when the webkit teams are part of the W3C! Opera is already implementing transitions using webkit-like syntax — that’ll be 2 browsers, so it’s highly likely to become a standard whether you agree with it or not.

      (For the record, CSS transitions and animations make me a little uncomfortable from a content/styling/behaviour separation point of view. But they’ll certainly be handy and many people will use them.)

      • Rob Crowther

        > Why would the final W3C standard deviate from webkit’s implementation when the webkit teams are part of the W3C!

        Any number of reasons: the other vendors might not like the syntax, or there are some other use cases that could easily be covered by changing the syntax slightly, or because the way it’s implemented in WebKit takes advantage of some rendering engine quirk which is impossible to replicate easily in other browsers.

        If the W3C working group was simply accepting, uncritically, the first syntax that came along for any feature they wouldn’t be adding much value. We would all end up locked into whatever syntax the original implementer came up with, possibly in a hurry, without much consideration of all the possible use cases.

  • ruNNin13

    I think that we need prefixes for now, at least until the rules will be standardized and will become a part of the specification… and of course when the implementation of them will be the same in all browsers. We won’t be needing them then. PEACE.

  • The thing to remember about vendor prefixes is that for all intents and purposes they say “This is not for use in building production websites”.

    Unless you are using them to backwards support older functions that are formalized in newer versions (-moz-inline-block for example) you really have no business trying to use them in deployment work!

    They exist for the sole purpose of testing what we someday MIGHT be able to use — someday as in a decade from now. You want to use it to test and report issues/problems, that’s what it’s for.

    With all the people are doing the stupid thing of jumping the gun attempting to deploy specifications like CSS3 — not even out of draft yet, it will be a miracle if it doesn’t create the exact same problems CSS2 support in IE5.x created.

  • Yes… In a perfect (vendor/browser) world, yes we could get rid of the prefixes but unfortunately in that case of browsers, vendors and standards the world we are in is far from perfect so the real answer is no.

    My opinion resonates with deathshadow60’s above who from the looks of things remembers the mess we got into when IE5.5 was released with its animated css filters or Netscape 4.xx and its implementations of various html/css elements.

  • Paul McKeown


    Tosh. It is fairly harmless to round corners or create text shadow using CSS 3; it can save a lot of time and pointless background images.

    • goldfidget

      It’s fairy harmless provided you own the result. I’ve not yet met a client who is happy to be told that the majority of their visitors will not see the pretty website they paid for.

      Most people don’t care about standards, CSS3 or the fact that rounded corner graphics are a bit clunky, they care about their own business.

  • Paul McKeown


    What you wrote really is nonsensical. If we had to wait for full standardisation, we would still be denied CSS 2.1. Web development is a practical matter, not some theoretical exercise. Use whatever comes from CSS 3 or HTML 5 as soon as it looks stable enough not to cause problems with interoperability or maintainability.

    • Unfortunately “as soon as it looks stable enough not to cause problems with interoperability or maintainability” is a non-existent theoretical state. All non-standard implementations create problems with interoperability and maintainability, that can only be completely resolved with full standardisation; which will never happen :)

      • cowbrown

        I’m with Paul.

        Read some books guys. Seek out new ideas and clever use of the technologies to hand.

        OR, forever remain in the 1990’s.

      • Paul McKeown

        Errr, yes, so your observation is that the web is in a constant state of flux. But apart from navel gazing does that statement say anything useful? If the web is continually evolving and standards lag browser technology by a decade or more, then, naturally, some device is needed to deliver format and interaction suitable to browsers of different capabilities. And no one wants to return to the era of the “hack”, do they? So either preserve the web in aspic or employ prefixes appropriately.

      • IMO, that speaks more to the state of standardization than anything else.

        Specifications remain in draft for years before they are upgraded to recommendations and in the meantime the drafts are promoted recklessly by vendors or other entities (Steve Jobs) to promote a side of an argument (HTML5/CSS3 vs. Adobe).

        I doubt anything decisive can be accomplished with that problem but I certainly can’t see how abolishing CSS vendor prefixes will make a positive difference. Perhaps going forward it will but only time will tell.

  • Keif

    To be honest, abolishing or not abolishing – until all users are using “most recent versions” of their browser of choice, it’s moot. You’ll still have to code to account for backwards accountability, which means:
    “standard” css3 property
    “browser specific” css3 property to insure backwards compatibility.

    I like the idea of breaking css3 in to “mini-specs” – approve small chunks of it at a time, so that at te very least developers know which browser vendor to yell at for their poor implementations.

  • momos

    throw the prefixes out from the moment you are recommendation compliant

  • Kev Adamson
  • aramando

    I really don’t understand the fuss over vendor prefixes. Yes, it’s a pain having to define a property 3 or 4 times, although when it’s often just a case of copying and pasting the same line and changing the prefix, it’s really not so bad. But the main point is that it’s always a lot easier than having to use some nasty hack to target a specific browser because that browser has a unusual implementation.

    Of course, we’d all like the specs to become standardised quicker and for cross-browser implementations to settle down and become consistent faster, but in the real world they don’t and vendor prefixes are a neat way of dealing with that.

  • Oliver

    I believe standards should be strictly adhered to and also definite.
    Having too many options and clauses in a standard just only makes room for confusion and weird interpretations.
    CSS missed several opportunities to right the wrongs of the past and in a way has carried over some of those flaws by introducing more flaws.
    The world I believe is ready for a new Web standard. And there is no time like the present to get that going.
    CSS can just be frozen as it is.
    The new standard can take the best parts of CSS or come up with an entirely different mark up.
    It will not be too difficult for a new editions of Browsers to support both web formatting standards.
    I’m even beginning to believe the committee that define some of these standards are just there because they enjoy the coffee being served, rather than being there for doing useful work.
    I mean what is with all these DTD ..Level 1, 2, 3 or whatever.. strict, transitional , blah blah..
    The browsers are just choking on unnecessary and verbose text that is just put in there to make someone feel happy.

  • Anders

    One problem with the vendor prefixes occurs when you access prefixed properties through JavaScript.

    In every browser, a dash indicates that the next letter of the property name in JavaScript is a Capital Letter. So “border-radius” becomes “borderRadius” in JavaScript. The same is true for vendor prefixes. “-moz-transform” becomes “MozTransform”. That makes it pretty easy to create a name translation algorithm.

    …if it weren’t for IE. IE does this differently. I discuss this at

Get the latest in Front-end, once a week, for free.