Two New Proposals to Solve the CSS3 Vendor Prefix Crisis

Web developers have been concerned about the vendor prefix crisis since February 2012. To summarize the issue, this is what should happen in an ideal world:

  1. Vendors implement experimental CSS3 properties using their own prefix, e.g. -webkit-transform, -moz-transform, -ms-transform, -o-transform.
  2. Developers can use the technologies today without breaking cross-browser compatibility. Properties can be listed with their prefixed and unprefixed names to ensure they work everywhere.
  3. Once a property becomes a W3C recommendation, all browser vendors can provide a stable unprefixed property, e.g. transform.
  4. Optionally, developers can remove the prefixed properties from their stylesheets. However, it’s not strictly necessary if the unprefixed property is defined last and CSS cascade rules apply.

This is what occurs in the real world:

  1. Vendors implement experimental CSS3 properties using their own prefix. In some cases, vendors promote them as an HTML5 “standard” even if they’re device-specific or never submitted to the W3C.
  2. Some developers use the proprietary property from a single vendor, e.g. only -webkit-transform. This might be owing to ignorance, laziness or because they’re testing a limited number of devices.
  3. Once a property becomes a W3C recommendation, all browser vendors can provide a stable unprefixed property, e.g. transform…
  4. but developers neglect to change their stylesheets. The site looks good in some browsers but worse in others even when they support the standard W3C specification.
  5. The vendors become concerned and add support for other prefixes into their browser, i.e. Opera implements the -webkit prefix for some properties. The prefix process is broken and, while it’s too early to predict the outcome, the majority of developers consider it to be a bad move.

We have discussed the issues at length on SitePoint; there are no easy solutions. However, two interesting proposals have been raised by W3C members during the past week.

Option 1: Unprefixed Properties are Supported From Day One

The first proposal comes from Florian Rivoal, Opera’s W3C representative:

When a browser vendor implements a new CSS feature, it should support it, from day 1, both prefixed and unprefixed, the two being aliased. If a style sheet contains both prefixed and unprefixed, the last one wins, according to the cascade.

Authors should write their style sheets using the unprefixed property, and only add a prefixed version of the property (below the unprefixed one) if they discover a bug or inconsistency that they need to work around in a particular browser.

If a large amount of content accumulates using the a particular vendor prefix to work around an issue with the early implementation in that browser, the vendor could decide to freeze the behavior of the prefixed property while continuing to improve the unprefixed one.

For example, you could use the following transform code in your CSS:


transform: rotate(30deg);

The property would be ignored by all browsers which had not implemented transforms. If there were a difference between two or more implementations, e.g. webkit browsers rotated anti-clockwise by default, you could override the property accordingly, e.g.


transform: rotate(30deg);
-webkit-transform: rotate(-30deg);

It’s a simple solution and easy to implement. Most existing stylesheets would continue to work and prefixed properties would rarely be necessary. In most cases, you would never need to update your CSS again.

However, what would happen if webkit changed rotation to the W3C-approved clockwise direction? Developers would need to fix their stylesheets by removing or rearranging the -webkit-transform: rotate(-30deg); property. Unfortunately, not everyone uses the same version of the webkit engine at the same time. You could encounter a situation where your site works in Chrome but not in Safari for several months.

Option 2: A New Vendor-Draft Modifier

The second proposal comes from François Remy:

Let’s introduce the “!vendor-draft” value modifier. I propose we use unprefixed properties from start, but with a token explaining which version of the property we built our CSS for:
border-radius: 3px !webkit-draft;

Any browser which is not webkit but implemented border-radius in a way that is compatible with the “webkit draft” can support the declaration. This is different from vendor prefixes: other browsers don’t impersonate webkit, they just acknowledge they support one specific property the way the webkit draft defines it. Browsers which are not compatible with that draft will just ignore the declaration. Browsers that change their implementation of a property are encouraged to iterate their “!vendor-draft” flag (using a version number, if appropriate).

This solves the issue by changing the property value rather than its name (in a similar way to the !important modifier). Again, the following transform code could be used:


transform: rotate(30deg);

But a default anti-clockwise rotation could be fixed in any browser adhering to a webkit specification:


transform: rotate(30deg);
transform: rotate(-30deg) !webkit-draft;

If a browser subsequently supported the W3C specification, the second property would be ignored.

It would also be possible to implement draft versioning, e.g.


transform: rotate(30deg);
transform: rotate(-30degrees) !webkit-draft;
transform: rotate(-30deg) !webkit-draft-2;

It’s a flexible solution which finally addresses the issue of properties evolving over time.

Unfortunately, it’s more difficult to implement and could take months to appear in browsers even if all vendors agreed today. It may be technically better, but it’s a fundamentally different approach which could break existing stylesheets. In the short term, vendors would probably support both prefixes and value modifiers — and that would lead to confusion.

I like both solutions. From a coding perspective, vendor-draft modifiers seems the most logical option but I doubt it can be considered until vendors “complete” CSS3 and begin work on CSS4.

Supporting unprefixed properties is more practical but will certainly cause versioning issues which couldn’t be fixed in CSS alone. But perhaps that’s the price you pay for using experimental technology?

Do you have a preference for either of these options? Or is it too late to prevent a vendor prefix catastrophe?

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • http://niteodesign.com Blake Petersen

    I’m all in on the Vendor-Draft method!

    • http://www.optimalworks.net/ Craig Buckler

      I like it. Eric Meyer has given his approval which is promising. But it’s a major change in direction and will take time to agree, implement and get word out. Until then, I’d be happy to see Florian’s suggestion in place.

  • http://www.simianenterprises.co.uk Gary Stanton

    Wouldn’t it be better if instead of using separate prefixes for each rendering engine, we used a single ‘beta’ prefix? Just a thought.

    • http://www.optimalworks.net/ Craig Buckler

      Possibly, but you’d have an problem if two vendors implemented a beta property in different ways.

      • Anonymous

        I have been thinking along the lines of ‘beta’ as well. How about this:
        When a vendor implements a new property, it can be accessed by their prefix, just like now, AND with a ‘-beta’ prefix.

        So if a developer want to use it, they should always use the ‘-beta’ prefix, unless there is a browser that has implemented it differently. In that case, they can use the vendor prefix of the offender. Once everything has stabilized, the standard name will just take over. Vendors who initially implemented the property differently can continue to support their vendor prefix way for as long as they want, but move the regular and -beta versions to the standard.

        transform: rotate(30deg);
        -beta-transform: rotate(30deg);
        -webkit-transform: rotate(-30deg);

  • Eric Naujock

    the first question I would have is why is any of this necessary. The vendor prefix models worked just fine except that some developers who did not pay attention to the spec could not follow the guidelines. Or were to lazy to do their job right. What makes anybody think that either of these two fixes will stop bad developers from using bad practice?
    This panic seems be being caused by browser makers breaking the model by stealing somebody else’s prefix and justifying it by saying nobody uses our prefixes. This is a bad plan at so many levels. Since when is identity theft a good solution to a lack of popularity?
    Those who are bad developers and are ignoring the bast practices should be shamed, educated about following best practices, or ignored. While most may not have the time too do everything and know everything following the W3c should be the first priority. If you want to do nifty things with vendor prefixes then go out and learn how to do them right.
    Browser makers also need to make the docs on their specific prefixes more visible. I should not have to hunt for 20 minutes to try to find operas varied implementation of a transform only to find they don’t have a vendor prefix specific version, and only used the W3c spec.

    • http://www.optimalworks.net/ Craig Buckler

      Thanks Eric.

      So vendor prefixes worked fine except some of the time?!! While I’m yet to see proof of their claims, the W3C members have discussed this problem affecting 10-20% of all sites. I agree browser identity theft seems wrong but developers caused the problem. Do vendors have a duty to serve several thousand developers or several billion web users?

      I’d like to see a few companies named and shamed, but doing that for millions of websites is not practical. And I’d bet both you and I have sites where we’ve accidentally forgotten a prefix or two. Education is the best solution but the damage has already been done. Would website owners be willing to pay for cosmetic fixes which affect a subset of their users who probably aren’t aware of the issues until they use another browser?

      The first proposal means that vendor prefixes become redundant in many cases. Why would anyone use -webkit-transform when transform is supported everywhere? The second removes prefixes completely and fixes the value which is more logical.

      • Ryan P

        I think the browsers have a duty to the developers – the developers have a duty to the users. Its not the browser maker’s fault if some developer can’t make pretty things in their program. I’m sorry but as someone who gets undercut on jobs, just to see them done poorly and wrong by those that undercut me is frustrating. Also my production sites only use W3C standardized properties, makes for a much better user experience when the site is the same no matter where they access it from.

  • Jason

    Aren’t both of these options really just half measures? Is it too much to ask to actually “fix” the problem instead of adding another layer to it? How about NO vendor prefixes? Or is that just css dreamland?

    • http://www.optimalworks.net/ Craig Buckler

      It’s CSS dreamland.

      For a CSS property to become a W3C standard, it must be implemented by at least two vendors. If everyone used the same unprefixed property, implementation differences would make that property unusable. Vendor prefixes solve the issue by allowing vendors and developers to experiment without breaking the web. It’s just they’ve taken on a life of their own…

      • Stevie D

        The biggest problem is the horrendous time-lag for getting features approved as part of the spec. A new feature is considered, and two browsers implement it in the same way. Given the speed at which Firefox and Chrome in particular release new versions, that could happen within a month. But then what happens? The feature sits in a filing cabinet somewhere in the basement of the W3 offices for another four years while the rest of the spec is finalised.

        Just as HTML5 is intended to be a living document that does away with future versioning, we need the same plan for CSS – a much faster process for new features to be officially added to the spec so that they can then be widely used without any vendor prefixes.

  • http://www.devseo.co.uk/ Alex Hall

    I just don’t know. It seems like this could just end up being the same scenario as current, a little way down the line. Some people won’t learn it, and won’t use it. Others won’t understand it, so won’t use it properly. Exactly the same as has happened with vendor prefixes in the first place.

    If I were to go for one of them I think the second would be more favourable. Everyone knows how to use !important, it’s basically the same thing. I do, however, forsee an issue where version numbers could get silly. I wouldnt’ fancy writing 5 lines of CSS just to support 5 variations in webkits implementation! I’m not sure how often they change, but the potential is there.

    What’s wrong with just using the defined W3C standard implementation and degrading gracefully wherever possible? Sure, that simply isn’t a solution for some, but it’s the way I’m considering heading for the more simple stuff because, at the end of the day, if an element doesn’t have a 2px border radius I’m okay with that!

    • Stevie D

      That’s all very well, but there have been times when browser manufacturers have implemented a pre-standard property differently. Border-radius is a case in point. It isn’t part of any specification yet, so there’s nothing concrete for manufacturers to apply. But different browsers dealt with it differently when there were two measurements given. So while you might quite happily live without a border-radius at all as a fallback, you wouldn’t necessarily want it to apply a border-radius incorrectly. So until it is standardised in a spec that is supported by the browser version(s) that the vast majority are using you need to have a way of identifying which interpretation of the property you’re writing for.

    • Fred B

      Yes, exactly! Surely, the end result should be that the site you build for a client should display correctly for them. They pay the money, you work for them. An end user, the customer of your client, couldn’t give a rat’s backside if an element has a 2px border radius or not. The end user wants information; transform, border radius, pretty things are irrelevant in their eyes.

      Most of my clients are acommodation providers. Their clientele want to see the accommodation and be able to book a room/rooms/whatever.

      As developers, we need to look at what the end user wants, not go on our little ego trips of how pretty we can make things and get so tied up in it that our sites don’t look the same and function the same across all browsers, across all screen sizes.

      Keep it simple, make sure it works on all devices and all browsers.

  • http://www.rachelreveley.co.uk Rachel Reveley

    Isn’t the whole point of vendor prefixes to beta test?

    If a broken vendor prefix breaks your website or causes a poorer experience then surely you shouldn’t be using it in the first place?

    On that basis I don’t understanding why all the fretting.

    I try to only use features once all the vendors have their ducks in the same line. I then repeat the same CSS but with alll the vendor prefixes and only because half the time the unprefixed version hasn’t been imlemented yet.

    Today was the first time that I have hit an issue where I want different CSS for different vendors and that was because Firefox becomes very slow when using multiple backgrounds with RGBA values and the background size property, and just my luck, I cannot get the -moz prefix to overide the unprefixed version.

    • http://www.optimalworks.net/ Craig Buckler

      If a property is unstable then, yes, it’s advisable to avoid it. In reality, that’s rarely the case. With the possible exception of linear gradients (which was addressed), most vendors copy the implementation of whoever added the property first.

      But remember this is NOT the same as software beta testing. It’s about establishing a new feature and agreeing its implementation. A property may exhibit bugs in browser X but that’s an entirely separate issue.

  • http://www.deathshadow.com deathshadow

    On the forums here a much more sane proposal was made, rather than vendor specific prefixes if an element is still in draft, then it exists for testing, not for production use… so what business does it even have being in the stable/public releases of the browser? Implement them in the nightly/beta builds so they can be tested by people qualified to test them, instead of having production developers using them before they are complete.

    End of problem.

    Draft, Alpha, Beta — they should actually retain their meaning; not for production use!

    • http://www.optimalworks.net/ Craig Buckler

      Remember we’re not talking about software products here – it’s features within those products. Alpha and beta concepts don’t apply and, whether you like it or not, it’s not the way the W3C process works.

      The W3C does not invent new features. That’s the vendors job and they’re free to implement whatever they like whenever they want it. A new feature (CSS property) can be submitted to the W3C for approval but will only become a standard when two or more browsers support that feature to an agreed specification (which could take several years).

      If new/experimental features were only available nightly editions, they could never become a W3C standard. In addition, those properties wouldn’t be used in the real world so testing simply wouldn’t occur to the level it is now. Even if a property could be “approved” in some way, the whole process would take far, far longer.

      Prefixes prevent vendors creating different implementations for the same property. However, properties are often stable long before it becomes a full W3C recommendation. We’ve been able to use border-radius for years, but it’s only within the past 12 months that you could use it without a prefix. Would you have been happy to wait?

  • James Golden

    Here is another proposal – and this is a little left-field, but hey…

    Have web browsers standardize on a rendering engine and be done with vendor-specific prefixes altogether.

    What is the negative impact of this? There are plenty of other browser features to be competing on – like ease of use, speed, tools, etc. All the engineers previously focusing on their own rendering engine could collaborate and with all that brain-power in one room, how quickly do you think we could adapt to technology changes (like our life today – apparently – demands)?

    • http://www.optimalworks.net/ Craig Buckler

      No! No no no no! No.

      The negative impact is that competition and evolution dies. We’ve only just ended a period with one dominant browser engine: IE6. Let’s learn from history.

      Besides, do you really think Microsoft, Mozilla and Opera would throw away a couple of decades work? Even if they did, how long do you think it would be before vendor X decided to fork webkit because they wanted a specific feature? You’d still end up with multiple engines.

      • James Golden

        Like I mention – there’s plenty of other browser features to be competing on. And the combined effort of browser vendors makes evolution happen faster – like we all want. Previous efforts aren’t thrown away if experiences are shared, the best of each is determined as a group and used to progress moving forward. Diplomacy amongst the thought-leadership prevents the forking. Make sense?

        The idea comes from the initial proposal of vendors incorporating each other’s prefixes in order to not make their own browser appear “broken” if (poor) developers are focused on a webkit-only approach. That seemed to be an indication to me that standardizing a rendering engine isn’t such a bad idea or that they’re not far from the idea. I am apposed to it (incorporating each other’s prefixes) because, personally, that’s not what we need – more complication in how we develop websites. I think the masses agree – for their own varying personal reasons.

        The end effect of all of this is that developing while having to tip-toe around various levels of browser rendering capability is an expenditure of a client’s dollars and risks presenting a poor visitor experience. We could do so much more for our clients if we knew that the development of a mind-blowing experience was going to be straight-forward.

      • http://www.optimalworks.net/ Craig Buckler

        You’re forgetting one small detail, James: browser vendors are competitors. Only Mozilla has no shareholders and even they have monetary obligations. The vendors may share technical details, but only because it’s to their commercial advantage. Even then, Apple has been accused of bypassing the process.

        Do you really think they could all work in harmony for the good of the web? Two people will disagree over implementation and scheduling details; we’re talking about five or more large companies with hundreds of developers working on hundreds of features. How long would it take to reach a consensus of opinion? Far longer than it takes for a W3C recommendation to appear now.

        Besides, what are all these other “browser features” they could compete on? Name one. Browsers are a shell for the rendering engine and there hasn’t been any major innovations since the advent of tabs in the mid 1990s. If anything, vendors have removed the feature bloat — Chrome has fewer features than IE7.

        Diplomacy amongst vendors sounds great. So did Communism. Neither consider the simple fact that people and companies have their own agendas and will always compete to gain an advantage over others.

  • Jim K

    As a web developer I want to develop using the best techniques. If I want some vertical text I’d much rather use the ‘draft transform’ style (a single line) then use many lines to accomplish the same thing in javascript. Just because W3C has not adapted a specific feature, you can’t compare it to the ‘beta’ phase of commercial software products. That’s comparing apples and oranges. That would be like MSFT or AAPL having to wait for some governing body’s blessing before it could release a new feature in Windows or OSX. The W3C moves at the same pace as other governing body’s … slowly! Remember how long IEEE took to adapt the 108Mbps standard (or ‘N’ draft)? Has it even been adapted yet?

    I would prefer Remy’s proposal with one more cascade. Maybe a ‘body’ style that defined the default prefix draftee (e.g. ‘body {prefix: -webkit;}’). That way you could shorten draft features/styles to ‘!draft’. Data integrity!

  • Joel Grissom

    I personally use the http://css3please.com/ website, which is current with the vendor prefixes for CSS3 properties.

    I realize that it is relying on someone else to keep up with vendor changes, but it is a good site that helps you to write variables once and they are changed for all prefixes and you can see a sample on the page.

    I like the first solution, which is NOT implemented by CSS3, Please! but can easily be adapted to move the non-vendor-specific code to the top of the cascade.

  • anonym

    There’s only one solution to that, they must follow the standard… they’ve created that technology and they turn it into complication… that’s what we are humans…. :(

    • http://www.optimalworks.net/ Craig Buckler

      Nothing can become a “standard” until someone’s implemented it and everyone agrees it’s the best way forward. No one is sitting in an office inventing standards!

  • http://anlenterprises.com Andrew Robinson

    Does this break if one vendor implements a property with a name for a property they think makes sense – but another vendor uses a different name for the same thing? If webkit had implemented border-radius but IE implemented border-curve – both for curved borders – how would this work. What if the W3C finalized on a standard that didn’t use either name – but was still the same property?

    • http://www.optimalworks.net/ Craig Buckler

      Two vendors could come up with the same idea and implement it differently but it rarely happens because all the vendors get together every few weeks for a cozy W3C chat about their latest ideas.

      The W3C can only set a recommended standard if it’s been implemented by two or more browsers.

  • Fred B

    Um , well, the cat amongst the pigeons……

    Why bother with Webkit? Didn’t we manage fine without it?

    I can still built very good sites without it and am willing to wait until all the nonsense is sorted.

    Just my 2 cents!

    • http://www.optimalworks.net/ Craig Buckler

      Are you serious? More than 4 in 10 users use a webkit browser! You don’t need to use webkit prefixes or any others, but you’ll be missing the cool stuff all the other kids are using!

  • Spudley

    The real answer to this problem would have been to have an “enable experimental features” switch in the browser config.

    If this flag was switched off by default, and assuming most end-users didn’t make the effort to turn it on, then:

    * Developers wouldn’t have the incentive to start cramming vendor prefixes into their code.
    * If they did use them, then they would have a stronger incentive to also include the non-prefixed version as well.
    * Browser vendors and the W3C would have an incentive to get the features standardised more quickly, so they could remove the prefix and have the feature available to most users.

    The down-sides of this idea:

    * Implementing it now will feel like a backward step, if it is applied to existing prefixed features, because those features will suddenly become un-available to many users. This could be worked around by allowing browser vendors a transitional period where the flag only applies to new features; existing prefixed features could remain unaffected.
    * The pace of change may slow down. Or at least, it may appear to slow down.
    * Browser vendors are the ones who will have to implement it, but they may not want to, as it would be effectively disabling the most “exciting” parts of their product. Dealing with this inertia is the hardest part, and probably why this solution isn’t already being considered.

    • http://www.optimalworks.net/ Craig Buckler

      If a property isn’t enabled in browsers it simply cannot become a standard. There would be nothing for the W3C to approve!

      Developers would not have an incentive to use it — prefixed or non-prefixed — because it wouldn’t be available to the majority of users.

  • http://www.meta-blogger.com Michael Hall

    Well, I try my best to simply stick with what is standard in all major browsers. I build it with plain old html and make sure it looks nice first, as all designers should, then i add on the bells and whistles based on what is standard across all major browsers. I generally don’t bother with the vendor specific stuff, as i feel that it is just way too much hassle and way too many lines of code just to make a site have curved edges, etc. I use them on personal projects, but generally don’t use stuff that is still changing or implimented differently across every other browser.

    Sure we could impliment these extra stuff and test them in each of the major browsers, i noticed that imdb.com looks totally different in IE compared with Chrome.

    For me the best way to handle this would be to build my own modular code with all the necessary forking to handle each of the major browsers and thouroughly test each module in each of the major browsers so i could just re-use as needed as most clients don’t want to pay for a per case basis. At least this would make it easy to roll out a new site quickly as well as make it easier to adjust when stuff changes.

    The problem with using non-standard stuff is that it is bound to change, and if you have moved on to another project then you have to go back to fix it over and over, so i just stick with the standard stuff unless it’s a personal project, and i generally don’t care about very outdated browser versions, upgrade your browser or too bad for you if you are stuck with IE7 from work, like i am this very moment. If it looks crappy i just wait til i get home to use my latest browser version.

    The corporate world needs to get with it, just as they update their anti-virus all the time they should
    update their browsers at least once per year, is that really so much to ask?

  • http://www.amep.com Lee Fairbanks

    Option 2 – The Vendor Draft makes it possible to set a style and walk away. Growth is painful; might as well get it right.