By Craig Buckler

7 Solutions to the CSS3 Vendor Prefix Crisis

By Craig Buckler

As we reported last week Mozilla, Microsoft and Opera have become frustrated with sites which only target -webkit CSS3 properties. It makes their browser look bad even when it implements identical or better technology. To solve the issue, they propose adding -webkit prefix support to the non-webkit browsers.

While this is largely a marketing decision, it’s a real problem. The solution appalls many web developers but we deserve our share of the blame. In this article we’ll discuss the options, pros and cons.

1. Nothing Changes

Assume nothing is done to solve the browser prefix problem.


  • Browsers continue to implement their own prefixes which you are free to use or ignore.
  • There’s nothing new to learn or test.
  • It feels right and the decision will please the majority of web developers.


  • We retain the four prefixed and one standard property. Stylesheets are larger than necessary and difficult to test.
  • Lazier or less experienced developers will continue to target webkit browsers only.
  • Chrome and Safari’s market share could rise to a point which makes other browsers redundant. We return to the days of single browser engine and innovation stagnates. The dark days of IE6-like dominance return.
  • Microsoft, Mozilla and Opera consider this to be a real problem: doing nothing is not an option.

2. Non-Webkit Browsers Support the Webkit Prefix

Assume IE, Firefox and Opera support webkit-prefixed properties.

Microsoft had already implemented -webkit-text-size-adjust in the mobile version of IE. While it’s a non-standard property for Safari (there’s no text-size-adjust), they listened to community feedback and pulled support. That’s unlikely to happen again if Mozilla or Opera start adding webkit properties to their engines.


  • It’s a quick and dirty solution which allows non-webkit browsers to render as well as Chrome or Safari.
  • There’s no need for developers to update their websites.
  • -webkit will become the dominant prefix; using -moz, -ms or -o will become unnecessary and CSS file sizes will reduce
  • It prevents webkit, Google and Apple becoming too powerful. If another vendor disagrees with an implementation, they can simply break it or provide an alternative. Developers may not be able to use the property in any browser.


  • It feels wrong: one browser should not need to masquerade as another.
  • It rewards sloppy development practices.
  • Differing browser implementations will make some properties unusable.
  • If developers retain webkit properties which fail in other browsers, more users will switch to Chrome and Safari. Other vendors will become increasingly irrelevant.

3. All Browsers Use a -beta Prefix

Rather than separate prefixes, assume every browser implemented the same -beta prefix.


  • Just one prefix to learn and use.
  • Stylesheet file sizes are reduced.
  • The property is obviously experimental; developers will be more cautious about using it.


  • As a solution, it’s little different to every vendor adopting the -webkit prefix.
  • Differing browser implementations may make some properties unusable.
  • Vendors are unlikely to remove their own prefixes; the situation won’t change.

4. Experimental CSS Properties Only Appear in Beta Browsers

Assume prefixed properties are abolished in all browsers. Newer experimental properties would only be present in nightly and beta releases — and they would not require a prefix.


  • It becomes impossible for developers to use prefixed code or target specific browsers in production websites.
  • Webkit-only sites are punished accordingly.
  • We all work to final standards — not future ones.


  • Far fewer developers will use and test experimental properties. It could lead to buggier implementations.
  • New properties may take several years to become standardized. Are we prepared to wait?
  • It’ll never happen. If a single vendor chooses to keep prefixes in their main release, they all will.

5. Vendor Prefixes are Dropped Following Final Implementation

Once a property is stable and implemented without a prefix, all previous prefixed versions are removed from the browser.


  • It’s a logical solution.
  • It removes unnecessary code. Library bloat is reduced and browsers become leaner and faster.
  • It rewards good development practices and punishes the bad.


  • It offers no immediate resolution for sites which only target webkit browsers.
  • It will break sites overnight — vendors will be reluctant to implement the policy.
  • Properties can take years to reach standardization and browser implementation schedules differ. Prefixes will break at different times so ongoing site testing and maintenance is required.

6. The W3C Agreement Process Becomes Faster

Assume the W3C adopt quicker methods of standardization and publish schedules detailing when a property is expected to reach maturity.


  • The existing process is too slow.
  • Developers will know when the final property can be used.
  • There’s less chance for vendor prefixes to gain widespread adoption.


  • The process is not intentionally slow. There will always be practical and logistical problems to overcome.
  • Vendors work at different speeds and it’s impossible to accurately estimate delivery times.
  • A faster approval process could lead to poorer implementations which negates the point of having a standardization process.

7. Better Evangelism and More Education in the Developer Community

We would not be in this mess if developers wrote cross-browser code and understood best-practice techniques.


  • It’s a good solution which we can implement today.
  • Anyone demonstrating example code with prefixed properties can provide browser support information with strong disclaimers.
  • Everyone can help. Fix your own code and contact sites which are not cross-browser compatible.


  • There’s no guarantee evangelists and developers will change their attitude.
  • Is it too late? Best-practice techniques are published but ignored.
  • There’s no definitive central information repository.
  • There will always be new, ignorant and sloppy developers. No one can become an expert overnight.

There’s no single solution to the vendor prefix problem. Personally, I favor a quicker W3C process, dropping prefixes after implementation and better evangelism. But those require a major shift in mindset rather than technical changes.

Ultimately, developers caused this problem: it’s up to us to fix it. There won’t be an issue if we shun prefixed properties or use correct cross-browser fallbacks. If we don’t, there’s a risk the CSS3 properties we rely on today won’t work tomorrow.

  • For me there’s an obvious answer to this problem: All browsers add the -beta- prefix in addition to their native prefix (so that both properties refer to exactly the same thing and one can override the other as normal via the cascade).

    This would mean we have the simplicity to add experimental features to all browsers in one declaration whilst still being able to override these declarations for specific browsers if their individual implementations of a given feature are buggy.

  • I think solutions 3 through 7 are not mutually-exclusive. I’d like to see them all tried in parallel. Maybe one will stick.

  • Tim

    The -beta prefix completely ignores the problem syntax differences after the declaration. Just have a look at how many vendor syntaxes there are for handling gradents. The beta prefix simply wont work if they don’t agree on the syntax first.

    • Exactly. But that *should* prevent developers using newer experimental properties which are in an early state and haven’t been agreed by all vendors.

      • Or maybe they’ll all just program for webkit again.

  • Not if it’s implemented like I suggest below. You could write something like:

    /* cater for webkit’s old implementation */ background:-webkit-gradient();
    background: linear-gradient();

    Bam. Problem solved.

  • James Willis

    Thanks for the post craig, I absolutely hate using any vendor prefixes to achieve an effect that should only really take a single line of code. I also would agree that the favourable solution here would be for W3C to speed up the process a bit. Thanks again for the read.

  • Matthew P.

    Everyone will have to suck it up if option 4 has any chance to succeed, but I think it’s the right move and is worth fighting for.

    A foundational principal of the modern web is that of cross compatibility and abandoning the old browser specific mindset during development, yet the tools needed to violate this principle come built into every new browser. The standardization process is slow, but if we cave in and make a habit of using new features before they’re finalized the web will always be full of sites that are continually breaking; This is what pressures vendors to further bend the rules for fear of their browser showing more broken sites than the competition.

    It we can’t count on the vendors to come together and reign in their prefixes now, can we ever count on them to discontinue a prefix, even when the standard is implemented?

  • Rick Mason

    What about building an expiry date of 1 year into the prefix? For example, if Mozilla introduced “box-texture” today it might look like:

    -moz-2013-02-22-box-texture: wooden;

    Every browser can experiment separately. The same browser could try a different syntax next month with a different date, or renew it with a different date if, after a year, they still think it has a future. And developers are reminded every time they use it that it’s going away.

    • I can see your point, but it’d be a lot of hassle to use those properties. I can just about remember the box-shadow syntax — adding expiry dates would make my head explode.

  • As usual, there really is no good way to fix things on the internet. Personally, I don’t believe for a second that just because a browser wins the browser wars that it’ll stop improving. I think that every single browser vendor has seen what that does and is willing to put the time in to make a great browser. Maybe they’d slow down a bit because there’s no real pressure, but I think that even MS would continue trying to improve if they won, now that they’ve seen the problems they’ve caused by leaving good enough alone.

    • Unfortunately, history doesn’t agree with you. Microsoft announced they would never create another browser after IE6 — there would be updates within the OS, but standalone browsing applications were dead and the IE team was disbanded. They only changed their minds when Firefox begun to win users but, even then, there was a 5-year gap before IE7.

      While it’s unlikely a browser could gain a 95% market share again, there’s no doubt that competition stimulates innovation.

  • Ryan P

    I there is an issue you haven’t addressed. If webkit wins out that is still competition as Apple and Google are two SEPARATE and COMPETING developers. Therefore I do think the best solution is for other vendors to accept the webkit implementations as they’re used by the webkit vendors and have them all DROP the prefix. You say the problem with this solution is the lack of competition (which of course breeds creativity) if webkit wins out, but there is already competition in that matter. My websites currently receive ~40% of their traffic from browsers other than safari and chrome, these browsers are already winning out – if the other developers still refuse to accept these implementations and try to make their own that’s there fault: it’s called a de facto standard. 8-track makers that refused to make turntables went the way of the dinosaur because they didn’t update and adhere to the de facto standard. That’s how things work: just because its versions of software instead of new physical products doesn’t mean it should be treated differently.

    • You really don’t everyone to follow webkit all the time. Did you see their original implementation for gradients? They’re not always in the lead.

      To use your 8-track analogy, the vendors each create their own players. However, some lazy music producers (web developers) are creating cassettes (websites) which sound great on Apple and Chrome’s players, but awful on others. Even though Microsoft’s, Mozilla’s and Opera’s players are technically better in some respects.

  • Paul

    The problem with vender prefix is not with w3c, it’s the vender.

    -webkit, -moz-, -o, -ms

    Regardless of readiness or any final decision from w3c, each vender can do without those prefix, but they chose to do it with, just to tie down the market.

    It’s for the business purpose, and we, developers, are the one who pay the price.

    There will never be one true standard, if we keep using vender prefix in the name of standard.

    • A standard cannot become a standard until a technology has been implemented by at least two vendors. Vendor prefixes solve many of the inevitable compatibility issues, but they’ve taken on a life of their own!

  • Do websites need to look exactly the same in every browser?
    Anyway, I haven’t tried it yet, but have you seen Lea Verou’s Prefix free?

    • Absolutely not, but the issue is that a site may look great in one browser but crappy in another equally-capable browser. Targeting a single engine is the problem; we’re returning to the dark days of “This site looks best in…”.

  • As developers, there is only one option we can affect directly: “7. Better Evangelism and More Education in the Developer Community.”

    Further, Craig states that we developers are the root cause anyway: “We would not be in this mess if developers wrote cross-browser code and understood best-practice techniques.”

    Rather than wishing for others to do what we’d like, it seems more effective for developers to take up the challenge. In particular, how can we make writing cross-browser code incorporating best-practices the easiest way to write code?

    What can we do with tools, libraries, or snippet collections to make the right way, the easy way?

  • Chad Garrett

    Option #8. When a feature has been standardized in CSS, deprecate the vendor prefix and display errors in the console to reflect that.

  • I’m surprised javascript isn’t mentioned more in relation to this discussion.

    Off the top of my head:

    8. The web-dev community provides a javascript library to allow the page author to specify unprefixed styles which are then conditionally converted to prefixed styles.

    9. Browsers only allow beta styles to be set from javascript.

    • It’s a possibility, but causes additional complexity and I guess some engines would have difficultly making a property work in JS but not in CSS.

      Besides, all you’re doing is making the prefixes a little harder to use. But once you’ve added that shim, it won’t matter to you. You may never change that JS again and it’ll still refer to the old vendor prefixes.

  • Chris

    Personally I don’t see this as much different as IE6~ days when MS was creating their own CSS (like filters). The CSS they were creating were based on what people wanted, so I don’t see how modern browsers doing their own thing is any different?

    I understand their approach was bad – but I just don’t understand when Apple or Google do it, it’s innovation, but when MS do it, they get slammed.

    Anyway I use LESS for my CSS needs. Couple this with “LESS Elements” I only ever have to write one line of code for each of these CSS Vendor specific styles and LESS Elements provides the mixins to add all 4. The advantage of this, if some other browser is introduced, I just need to update one Elements file and all my code remains unbroken.

    • In my opinion, it’s worse than the IE6 days. IE6 evolved during a period before standards existed. Microsoft had to make decisions which were subsequently overruled (the box model being a case in point). Even so, in 2001, IE6 was the best standards-based browser available. It only caused problems as the specifications and competing browsers evolved but IE6 didn’t.

      We now have a vendor agreement process. Unfortunately, Apple has been adding Safari-only properties with a webkit prefix, not submitting them to the W3C, and promoting them as an HTML5 ‘standard’. Their decision to abolish Flash because it wasn’t part of the “open web” seems a little hypocritical now.

      • Chris

        And this is exactly what bugs me with Apple – I’m not an Apple fanboy, nor am I directly opposed to them. They do some things fantastically, but creating their own standards and marking them off as an HTML5 standard is a bit rich.

        They can obviously do it because all developers will come to use their -webkit- styles because no one wants a client saying “I paid you x amount and the site doesn’t even work on my iphone?”

  • José

    Perhaps the solution is that all browsers use the same rendering engine and they’ll compete and differentiate from each other based on other features such as better ad-ons, better UIs, etc.

    The rendering engine would be open source and developed by all the vendors in conjunction and based on the latest standards, beta features could be prefixed with -beta.

    • No!!! A single rendering engine would still stifle competition. Besides, it’ll never happen; vendors would simply fork it to implement their own tweaks. Before your know it, we’d be back to four or more code bases.

      • Ken

        I think a single rendering engine, legally enforced, would be grand. Then vendors would focus on the UX feature/components for their own software. IE 10 with better touch screen support, FF w/ tab groups, Chrome with superior syncing capability the list goes on and on.

        At the end of the day the average user could care less who renders what and how. They use the browser they are using b/c:

        1- they don’t know any better,
        2- it’s available
        3- referred by a friend
        4-installed by relative etc.

        A small percentage of the browsing population actually chooses a browser based on its rendering capabilities. I wish this wasn’t the case but it is. Pinning the blame on developers for targeting specific browsers only is kind of a chicken and egg thing in my opinion. Would we really develop a hatred over certain browsers if they all just played nice with the same code? Would we foster bias in development for one browsers’ support of CSS3 more than another’s? Then browser selection would actually boil down do ‘Which one do you actually like to surf the web with?’, not ‘Which browser do you _have_ to surf the web with?’

  • Roger

    IMHO, why do we need a standardization called “complete CSS 3”? Why can’t we have a process that makes a bunch of standard rules at a time. I mean more shorter cycles, I think we don’t need to wait five or ten years to have all these good rules standardized. We could have CSS 3.1 with many rules that we already use with the same syntax but we are obliged to use accomplished of these prefixes.

    • CSS3 has already been modularized for that very reason. There is no single “complete” specification, but many specifications which are at various stages of agreement and implementation.

  • Daniel

    Can’t they all use some kind of vairable (like “*” in Windows) in stead of webkit, moz, ms and o?
    Like: -*-text-size-adjust that supports all types and then just develop for the future with one format and have this fix just for legacy issues?

    Consider I’m a noob at webdesign, so please be gentle if I didn’t get it or made a bad or stupid comment.
    Still, feedback would be great though ;-)

    • Don’t worry Daniel – we were all noobs at some point!

      Actually, though, I think that’s a good idea. It’s similar to having a -beta prefix in that all browsers would understand and use: “-*-transform”. But if webkit’s implementation was different, you could still use -webkit-transform and it’d pick that in preference. It would reduce CSS file sizes and developers would be keen to use it.

      My only hesitation is that “-*-transform” would always be supported so there’d be little point using the real “transform” property when it eventually becomes stable.

  • mfcat

    Six and seven need to happen no matter what.
    Another option: developers stop using any prefix in published web site. Sure, test out the prefixes and provide feedback to the browsers and W3C, but avoid the inherent problems of using prefixes. (See one, and add the problem of cleaning up code when W3C adopts the properties.)
    If developers stop using prefixes in published web site, the W3C will have to start moving faster, as demand for implementing the new properties will become louder.

    • Can you see that happening?… “Sorry boss, but that animation you like is coming out because I want the W3C process to be more efficient.”

  • I wouldn’t call myself a developer, but I write an awful lot of css. Knowing that the prefixes mean that a certain style is not yet a standard across all browsers makes my conscience prickle when I knowingly resort to using it. Does no one else feel like they are breaking the rules when they use prefixes?

    I can understand that it’s good to be testing the styles for each browser using the prefixes, but I do think that our final css should be standard based as it is drummed into us through whatever we read about the subject online. There are usually other ways to perform the same effect even it means resorting to graphics. Perhaps we are just being lazy and taking the easy way out. That’s how I feel about my own actions, it’s easier to write code than mess around with images.


    • I don’t see any problem using prefixes if you:

      (a) provide them for all browsers even if they’re not currently supported: -webkit, -moz, -ms, -o and non-prefixed.

      (b) are prepared to do a little testing when new browser versions appear. Eventually, you can rip those prefixes out of your code.

  • The problem existed long before this particular new “crisis” appeared. The sensible solution was to change the way one writes CSS.

    It’s a matter of choice. For me, with SCSS I can easily create libraries of mixins (templates, in this case, that can also take arguments) to cover all the cross-browser issues in a smart and coordinated way. And that’s not all. I can create typography, centralized code vaults, like typography vault, reusable in every web project I take, with very little effort. Such is the power of SCSS.

    As such, our efforts should cover the aspect of sensible solutions, changing what you can and adapt, rather than trying to dictate around vendors or consortium. And tools like SCSS do create a softer layer between implementation troubles and our coding efforts, keeping us DRY and safe from any new “crisis”.

    In conclusion, stop writing CSS as our “ancestor” did :) Get smart. Or SASSy. Or SCSS. Or…

    • Those are good solutions (assuming the projects are kept up-to-date). Unfortunately, it requires developers to know they exist, be capable of installing it and learning a new syntax. I doubt they’re for everyone, but they could certainly help many.

  • javascript has a similar problem with the different browser manufactures. The solution that really rocks is a jQuery library. jQuery handles the differences between the browsers, so I don’t have to muck with the DOM differences of intrepretations. And, I don’t like to bloat my code. And my CSS3 validator won’t give me a validation but a lot of warning and error messages. It’s a total pain in the keyboard to have to even remember what browsers go with which -‘s.

    So, my suggestion is that some enterprising group come up with a “S3lib” library to incorporate all the various versions of the – this’s and – that’s. Then we can take advantage of a new standard as quick as the S3lib finds a compatible solution.

  • Gerry Danen

    Perhaps this is an ignorant-of-the-facts observation, but my JavaScript seems to work fine on all browsers, html is getting there, why is CSS such an issue?

    We seem to be catering to browser vendor ideas and sloppy developers, but what about the poor user experience?

    It’s like quirks mode in IE trying to make older sites look better, but breaking new sites.

    • Don’t forget that JavaScript — or, more specifically, ECMAScript — is an international standard. Even the bugs and quirks are replicated across browsers.

      The same is not true for browser APIs. Take file drag and drop – it works in Chrome and Firefox, but not the other browsers. But you can still use it because you can check for support and act accordingly.

      CSS is different; it’s not possible to check support because it’s not a programming language. Therefore, -webkit-transform won’t work in Firefox (yet) and -moz-transform won’t work in Chrome. You need to specify both, as well as the -ms prefix, -o prefix and prefixless property.

      That said, vendor prefixes are coming to JavaScript too. We’ll have identical issues if developers target one browser in preference to others.

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