By Craig Buckler

The Impending CSS Vendor Prefix Catastrophe

By Craig Buckler

Developers have a love-hate relationship with CSS vendor prefixes. They allow us to use bleeding-edge technologies at the expense of long-winded declarations:

background-image: -webkit-linear-gradient(#fff, #000);
background-image: -moz-linear-gradient(#fff, #000);
background-image: -ms-linear-gradient(#fff, #000);
background-image: -o-linear-gradient(#fff, #000);
background-image: linear-gradient(#fff, #000);

It works well in theory but consider what happens in the wild:

  1. Experimental properties are often implemented in the webkit engine first and there’s no guarantee they’ll be replicated in other browsers.
  2. It’s often difficult to determine whether a vendor-prefixed property is part of the CSS specification. Some vendors don’t submit properties for standardization.
  3. Even if the standard property changes, the incorrect vendor-prefixed version continues to be supported. Your old code still works; you won’t revisit it to correct the implementation.

You’ll often find sites using the -webkit prefixes alone — even if other browsers support the property or it has widespread availability without a prefix (such as border-radius). Chrome and Safari therefore look better than competing browsers — and the other vendors aren’t happy.

The issue was raised and discussed in the W3C meeting on February 7, 2012:

Web standards activists are teaching people to use webkit. You will see presentations from all the web standards advocates advocating people to use webkit prefixes.

Our job is to solve interoperability.

At this point we’re trying to figure out which and how many webkit prefix properties to actually implement support for in Mozilla.

If we don’t support webkit prefixes, we are locking ourselves out of parts of the mobile web.

Let that sink in for a moment.

Non-webkit browsers will support the -webkit prefix. That is the solution being considered by the W3C.

The idea is likely to fail miserably. Two or more implementations of the same webkit property won’t be compatible so developers won’t be able to use it anywhere. No one wins — including Apple and Google.

But I’m more concerned about the irreparable damage it’ll cause if the solution is successful. Once developers discover webkit prefixes working in Firefox, IE and Opera, they’ll expect them to work on all properties. Webkit-only adoption will rise exponentially and the vendors will be forced to implement the prefixes throughout. At that point, webkit properties will become the de facto standard regardless of any W3C specification. Game over: the open web is closed.

The implications also go further than CSS: many of the new JavaScript APIs have vendor prefixes.

Who’s to Blame?

We can point the sticky finger of failure at:

The W3C Working Group
It takes too long for web standards to reach maturity. That may be unavoidable but browser vendors are bypassing the process.

Browser Vendors
In their rush to push new technologies, it’s too easy for vendors to add a prefix and forget about it. Web developers require more information: is the property being considered by the W3C and when will the prefix be dropped?

In an ideal world, experimental prefixes would disappear once the browser implements the standard property. Vendors won’t do that because it’d break sites, but they could do more to highlight the problem, e.g. provide obsolescence detection tools or output error messages to the developer console.

Apple and Google
Both are guilty of promoting webkit prefixes as though they’re a standard part of day-to-day HTML5 web development. Apple has been accused of actively working against the W3C.

Mozilla, Microsoft and Opera
Other vendors are often months behind the webkit browsers — if not years. Adding webkit prefixes is a ludicrous solution: it’s time to up their game.

Technology Websites and Evangelists
We all love cool demonstrations but evangelists often neglect to mention that properties are experimental and may never have full browser support (and, yes, that includes SitePoint). Ideally, code should work in at least two browsers; at least it would indicate that multiple vendor prefixes are required.

Web Developers
We’re too lazy. We’re writing browser-specific code and, while we may have good intentions about correcting it later, we rarely do.

Do you recall the last time developers targeted a specific browser? It was IE6. We’re still living with the legacy of that decision a decade later. Do you really want history to repeat itself?

It’s Time to Act

I’m opposed to non-webkit browsers supporting webkit prefixes. At best, it makes prefixes unusable. At worst, it breaks the whole standardization process. You may agree or disagree but make your opinion known to colleagues, in blogs and on social networks. The W3C and browser vendors will listen to your feedback; you just need to provide some.

Then test your site in multiple browsers. A little graceful degradation is fine but neglecting one or more modern browsers with equivalent support is not. Fix the code, otherwise your site is contributing to the problem.

  • Aaron Osteraas

    I am a WebKit user. I use Chrome, and I use Safari, because they don’t smash resources, have less obnoxious updates, etc etc.

    However, this does indeed compromise the state of the open and standard(ish) internet.

    If Microsoft and Mozilla want this, and people who choose to just use webkit prefixes, they should do more to be on the bleeding edge.

    My 2c anyway.

  • Ben

    Totally agree with you Craig, this ludicrous proposal from the W3C would reverse the whole principle that prefixes were founded on!

  • Matthew P.

    Vendor prefixes were intended to offer a tentative implementation of properties before they reach recommendation status… Each vendor is able to change their own implementation for experimentation/development purposes, and developers can test out these features to learn about them and contribute toward shaping their evolution and eventual standardization. The fundamental point is that these properties are entirely separate from the spec to avoid polluting it – They exist entirely for the standardization process, and nothing else.

    I’d say it’s the vendors that have abused their own tools here. Really, prefixed properties should probably not be supported on regular browser releases; They’re meant for development, so support them in development versions (alpha, beta, nightly builds etc.) or disable them by default. Making prefixed properties available on the average user’s browser gave developers the incentive to rely on them prematurely, as well as the means and incentive (given the inconsistent implementation of properties) to actively target specific browsers.

    Unfortunately non-webkit browsers will just have to tough it out and take one for the team – Their current solution to support -webkit- is a panicked, hacky response that fails to address the heart of the problem and undermines the purpose of prefixed properties. There are a bunch of sites out there that offer poor cross browser support for features that don’t technically exist yet. So what? Moving forward, if the vendors want to implement a collaborative, less volatile prefix (-w3c- anyone?) to include in standard browser releases to tide us over until the property is standardized they should go ahead and do that. But if they expect developers to follow the rules and treat it properly so should they – it should only implement the property as accurately as possible compared to it’s specification.

  • The main point I want to make is that blame is less important than the solution.

    The solution is simple. If Webkit stops supporting prefixes when the non-prefixed implementation has been available for a suitable grace period, the problem will go away. That will force management to give the developers time to write the code correctly, even in web development “seat shops” far away from Sitepoint and A List Apart.

    I wrote about that in length at my blog.

    As to Webkit being “years ahead” – perception vs. reality i a tricky subject. According to Lea Verou’s test actually Firefox nightly supports more CSS 3 than Chrome’s dev channel build. Firefox has a truckload more ECMAScript features, pioneered both WebGL and the sound api, etc.

    The fact that some people think that Webkit is months and even years ahead perfectly illustrates the problem. Other browsers are ignored even when they offer the same or better capabilities.

    There are four distinct technologies that Webkit did pioneer and those technologies are often confused with the complete CSS 3 package: Gradients, transformations, transition and animation.

    An example of the opposite: One can do very cool things using SVG filters and masks on HTML content in Firefox. The syntax is unwieldy – just like the original gradient syntax from Apple was – but capabilities are huge.

    A small subset of this can now also be done in Webkit based browsers. I’ve seen plenty of demos about that subset, that completely ignores the capabilities in Firefox, not even by mentioning that they exits.

    Perception != Reality

    • I wholeheartedly agree that webkit isn’t necessarily more advanced than the other browser engines but they did implement the cool and exciting stuff earlier. 2D/3D transformations and animation capture the imagination more than SVG filters and JavaScript APIs. In that respect, Firefox has only just caught them, Opera is patchy, and IE9 — which is almost a year old — doesn’t have them (or text-shadow for that matter).

      The main problem, however, is the mobile web. Quite frankly, I’m a little tired of iClone interfaces but it’s what mobile developers aspire to. And they’re prepared to follow Apple’s lead even when it’s at odds with the open web.

    • I agree with that. The problem is that Apple locks in a certain market: iPhone users, iPad users, and Macs (unless they install a different browser there) and these people won’t move away from using the “default”. Same with Android and Google. Not many people install a browser on their phone that’s non-default. I have Opera on my phone but that’s it, Mobile Firefox sucks, terribly.

      And now that Chrome is said to overtake Firefox, it’s basically “winning” out, and more people support only THAT browser. I’ve seen so many sites that say “best viewed in Chrome” or “works correctly only in chrome” that it’s ridiculous. There are devs that test only Chrome…and then IE because IE grabs the non-tech people.

      I think in the end, all browsers should support only the STANDARDS of today. It shouldn’t be a “standard” to support draft/beta properties. That’s why they’re “draft” and not “standard”. It’s dumb. And I blame both mozilla and webkit for this. They should be pushing W3C to standardize border-radius rather than taking the easy way out and letting people use the draft with a prefix.

  • Sharing webkit prefixes is the most absurd thing I’ve ever heard since the introduction of vendor prefixes. Either remove vendor prefixes altogether, or stick to your own vendor prefix.

    • I’m agreeing with you in that vendor prefixes were dumb to begin with anyway.

  • I think it’s time for Webkit to give away “I’m with stupid!” t-shirts for the users of their rival browsers that contemplate shooting them self in the foot like that :)))

  • Milo

    “In their rush to push new technologies”

    This. I’m following all the relevant blogs and all I see is a near-constant stream of “look at the cool new thing you can do in the latest pre-alpha version of our browser!” It’s ridiculous. I love brand new shinies as much as the next guy, but when it’s clearly having a bad effect on the browser landscape as a whole, you need to slow down.

    Vendor prefixes were implemented so that browser vendors could implement new features before they were “ready”. This let the vendors point out implementation problems, and would let them get some real-world feedback from sites that use them.
    If we can agree that vendor prefixes are really just our industry’s version of “beta”, then perhaps we should limit their implementation to beta versions of browsers. It would let us test all the fancy new shiny, without subjecting the actual real world to things that are, by definition, not ready for public consumption.

    • Pageo

      Yes, I agree.
      Use vendor-specific and emerging techniques when it’s cost-justified (including the cost of ongoing maint), else stick to standards (whether de facto or published).

  • Sharing -webkit- is a very bad idea and I’m very against it. For example Opera uses -o- prefixes only when elements are going into specifications and they don’t “make up” stuff as -webkit-. I think the best way it would be to find a solution to avoid prefixes.

  • Couldn’t agree more! Webkit is turning into IE6 and this time, web developers are to blame.

  • This is a huge potential issue. If you haven’t already signed, WaSP has created a petition to stop the madness:

    • Thanks for the link, Aaron. It’s received over 500 signatures so far.

  • Mike

    Who can I contact at the W3C to not support this effort?

  • Helen Robertson

    We are finally able to build a website without using tables for layout because the browsers now consistently support W3C Standards.

    Breaking this process to add a drop-shadow is nuts.

  • Tim

    This issue is 100% without a doubt the entire fault of Microsoft. If they had developed IE like they were supposed to, we would not be in this mess. It was the most popular browser for years, since the 90s. There was even a Mac version that was actually really good. But instead of adopting standards and keeping the browser updated and fast, they went in their own direction, really just to be different. There was no reason for it.

    • You really can’t pin this one on Microsoft. It has echoes of the IE6 problem but we, as web developers, must take most of the blame. By targeting a single browser (or, in this case, a rendering engine), we’re making it impossible for people to use an alternative. We’ve learned nothing.

  • Why not WAIL about ms:scale? Microsoft is the usual prefix target. Thing is this: [i.e.] That Is, or Safron, or Chromium, or even good old Operaaaahh and The Fox, it’s all the same. Their engineers are ‘Donglers’. They dongle goodies in front of folks like Craig to excite labile rant and wail. In the end, their dongles incorpoate big CA$$$H devices where money pumps this public circus.

    [niblenibblenibble] Squueek-Squeeek-Squuuuekkk

    [nibblenibble ….

  • Chris

    The nearly exclusive use of Apple products by front end developers is the cause of this. If they can see their new designs on their iPads, iPhones and Macbooks, the job is done. The rest of the ‘primitive’ products, who really uses them anyway?

    Of course, that’s ridiculous thinking. I can’t believe people at the forefront of this conversation are seriously considering this.

    • I do think this is a big part of the problem. There is a higher than average proportion of iPhones in the IT industry. It’s too easy to forget that 60% of mobile web users aren’t using webkit devices (and there are those with iPhones/Android who prefer Opera, Firefox or an alternative).

  • massacre

    Not sure what the big deal is here, if you browse the web using Safari/Chrome you get the latest features of webkit, if you don’t you gracefully see less funky stuff.

    • What if you’re using Firefox which more or less matches Chrome’s feature set (and exceeds it in some cases)? The only reason Firefox displays “less funky stuff” is because the developer has not bothered to support it.

      Targeting/testing a single browser/engine is the single biggest cause of web compatibility issues. It’s the reason IE6 became so dominant and still causes grief 11 years after it was released.

  • ROFL
    How is adopting the -webkit prefix more benificial to a non webkit browser than just implementing the actual non prefixed property instead?

    • Because developers are using the -webkit version instead of the non-prefixed property. The result: your site looks great in Chrome and Safari, but crap elsewhere. A user who happens to discover this will simply think Chrome is a better browser. Understandably, Microsoft, Mozilla and Opera aren’t happy about that.

      • ralph.m

        “Because developers are using the -webkit version instead of the non-prefixed property.”

        Do you mean that people are using -webkit-border-radius but not adding in border-radius as well? Surely developers know that the non-prefixed property should site at the end of the stack. If not, why mollycoddle them? It’s just ridiculous.

        It would be nice if the w3c would hurry up a bit, but this rush to use things that aren’t ready yet is going to land us in trouble for many years to come. Sigh.

      • Yes – that’s exactly what’s happening. Mozilla are looking into the proportion of sites affected and considering which webkit properties are the best to support. I suspect mobile sites will be the worst culprits.

        The problem is exacerbated by Apple adding webkit properties which are not submitted to the W3C – there isn’t a non-prefixed version.

  • Thank you for repeating what I’ve been saying for almost half a decade now!!! All this jumping the gun on specifications not even out of draft is the EXACT same thing that happened with CSS 2 under IE 5 — and the entire cause for headaches like the ‘broken’ box model, oddball behaviors and differences, things like the quirks mode trigger…

    …and with everyone jumping on the HTML 5 and CSS3 bandwagon before it’s ready, WE’RE JUST SETTING UP FOR ROUND TWO OF THE SAME PROBLEMS!

    Just like all the “gee ain’t it neat” bloat, sleazing out solutions any old way and “sophisticated internet investor will give cash for vague promises” is building towards the same situation as the previous dotcom bust. It’s really depressing to see everyone making the same mistakes all over again.

    • It is.

      However, we don’t want to stifle innovation. A standard only becomes a standard once it’s been agreed and implemented by two or more vendors. Prefixes were meant to solve the inevitable compatibility issues but they’ve started to cause their own set of problems.

      The most reliable solutions would be:

      1. Vendor-prefixed properties are only supported in the beta release of a browser. Unfortunately, that could mean we have to wait several years for the W3C to agree a reliable standard before it can be used.

      2. Once the final property has been implemented, vendors remove the prefixed version. Developers would see their sites fall apart overnight, but it’s the price you pay for using experimental technologies. That would be my preferred option but it’ll never happen.

  • tanks for share

  • It seems as if Apple and Google were ruling the web and also the W3C. I am using vendor prefixes in my designs, but not only for webkit but for all ( because for aesthetic reason I want my sites to look more or less the same on all browsers). It would be a great relief if the vendors would have to support the W3C standard version without the prefix. What if the web would be dominated by only the webkit companies in the future?

  • Tim

    I blame developers for using non standard prefixes without a compatibility layer, and implementors for being to weak willed to off a feature when it’s past it’s use. If the developer does not implement compatibility properly they should be punished when the prefix switches over to the standard by having that feature no longer work in the new version of the browser. These problems are caused by letting novice developers dictate how standards are implemented. They need to learn how to use tools to do things properly.

    • I agree, although some companies (ahem, Apple) have been promoting webkit-only code as if it’s part of the HTML5 standard. It’s not surprising there’s some confusion.

      One idea which has been put forward is the -beta prefix which would be supported by all browsers. It’s obviously an experimental property and implementations will differ across browsers so it’s less reliable and developers won’t be able to depend on it until it’s reasonably stable.

  • Alex

    So, a standard becomes a standard after two vendors adopt it? That’s a horrible way to determine a standard.

    • Why? All the vendors are (supposedly) working together. The W3C is not responsible for innovation. It’s why you can use HTML5 and CSS3 today; you don’t need to necessarily wait for a standard to be agreed and documented.

  • Great Article, and i think that at the end is everybody faults, the continues re invent the wheel, and us trying to use the latest technology.

    Thank you Craig!

  • I think the responsibility falls on W3C. They should be standardizing the web, and often it takes them a very long time to do so. I don’t think Google and Apple are to blame, I turn to webkit to do many things because it’s always up to date with the latest features. IE still can’t get regular CSS right in it’s browser, and Firefox has turned into a huge memory hog (my system at least).

    And it’s going to take time for Chrome and Safari to undue what IE has done. I know people who literally cannot tell me the name of the web browser they are using. Whether that be a generation gap, an intelligence factor, or something else – some people are oblivious that their are options and alternatives for browsing the internet.

    I’d be on whoever’s side has the most support for standard code, and who is trying to push the technologies. IE doesn’t do this, and Firefox’s performance lately (though I love them) has been outlandish. (No I’m not on a beta cycle). So kudos to Google and Apple.

    • Remember this isn’t strictly about Apple and Google, but webkit. The problem is that developers are targeting webkit-only browsers in the same way they targeted IE6 a decade ago. I don’t think the problem’s quite as severe but we need to put a stop to it now.

      And don’t think that webkit are always ahead of the game. Mozilla have caught up and are overtaking in several respects. IE10 is looking to be a very capable browser. And Opera is probably ahead when it comes to HTML5 support.

  • Shari

    I like the idea of using -beta or something similar. It is an indicator that it’s not standard, and easily replaced throughout. This would also make it cross platform if it’s being used in that fashion until it becomes standard. The idea of having to WebKit for every vendor is insane.

  • Patrick

    Just wondering:
    Which client will be satisfied with a product that only looks good in one or two specific browsers? I don’t think there are many. I think a client would feel quite screwed by the developer when he/she finds out… I don’t think that it’s the job of the W3C to correct such laziness.

    My two cents

    • I’m with Patrick. W3C, get some b***s and sort it out. Much as I love seeing progress and fancy new techs I think my job is harder than it needs to be because of this ‘browser war’ making me write more code. It’s complete madness and creates tons of extra man-hours in designing, testing and correcting… very inefficient!

      And on the whole, clients don’t get it – they just want their site to look “pretty” without the excuses and long explanations about support and workarounds.

      And this issue just makes a mockery of a Standards body not being assertive with the standards. Google et al, preach lean and good coding standards but in reality I have never seen a Google (& others) webpage pass W3C Validation !!

      I certainly feel pressure to code off-standards as my cleints want something they have seen on the Apple (who annoy the hell out of me for some of their tactics!) site …..

      It’s a ‘we are the coolest’ war and this is gonna get messier and harder whilst we have uncontrolled maverick “standards”.

    • I agree, although it really depends on the client and the skills of the developer. Many clients don’t know what browser they’re using and they’re happy if the site works on their PC. Some less conscientious developers will not bother developing or testing other browsers. Both parties are ignorant of the consequences.

      This is a good reason for vendors dropping prefixes once the final property is implemented. It rewards good development practices and punishes the bad.

  • mike ritter

    It seems like we developers shouldn’t be locked in to our designs lasting forever. I tell my clients the effective life of their website will be two years. Our frameworks are developing at least that quickly.

    W3C should adopt a life cycle development model.

    MS staying involved in our community might push us toward more universal adoption IF we bend to their culture and drop our biases. MS, the Webkit gang, Moz and O have agendas — gotta get ’em on board.

  • Obviously this is not the most optimal way of doing things. When you define a standard i think one of your primary goals should be to make the most optimal standards.

    Clearly overtime, this is going to add to large amounts of wasted bandwidth and sloppy CSS.

    I think they should just get rid of these stupid extension and everyone should have to follow the same rules, the end result will be so much better and a real standard.

  • When I was just a web apprentice (IE4 and Netscape) I used to dream of standards to write code once and it worked. W3C promised us that and I used xHTML 1/CSS2 for many a year with reasonable success but alas I am stilling dreaming the impossible of global standards
    – in fact, now we have such a myriad of browsers it just gets worse and I am drowning in a sea of flunky widgets just to appease fancy-pants animations and round corners… superfluous and wasteful.

  • Jon Alstead


    Crazy idea. Hope it never happens and the idea is left in the dark room to fester with the likes of IE6.


  • Hello,
    I would personnaly try to use as less as possible -webkit properties as well as specific browsers properties except if I am forced (transparence for example) but there are plenty of standard combinations to make in order to have good websites. It is always interesting to test those new technologies that can be the next tech buzz but… W3C stands as the garanty for my clients websites to work quite properly on many different Browsers/OS without coding plenty of specific codes hard to maintain (and not interesting for clients).
    A good website should have 3 css files to carry the design code not for specific properties but for different resolutions : normal, mobile and print layouts taking the lowest resolutions in those cases.

  • Blame IE ! IE is guilty of reducing the internet evolution

    • You can blame IE and Microsoft as much as you like but, ultimately, it was web developers who ignored standards and implemented IE-specific code. And now they’re doing the same for webkit.

  • As long as Mozilla actually fixes the implementation when handling -webkit prefixed styles, and also adds support for un-prefixed versions of the same properties (or identical support for the -moz prefixed versions), I don’t have a problem with this.

    And as far as revisiting the websites and removing prefixed properties, when do you suppose that should happen? Browser updates in the corporate world still seem to take decades in many cases, and older phones are often left out of the newest OS and browser updates all together. So I don’t see ever getting rid of most prefixes during the lifetime of the average website design.

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