Not Supported

Leave it to PPK to come out with a bold statement like, "CSS vendor prefixes considered harmful". Moreso,

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.

The problem is that they are necessary. Look at Safari's implementation of border-radius compared to the rest. I still can't remember if it's border-radius-topleft or border-top-left-radius. If they had gone without the vendor prefix, they'd be in quite the pickle. Or worse yet, web developers would be.

The vendor prefix does two things:

  1. It allows browser developers to test new functionality without fear of a changing spec.
  2. It warns web developers that things are in flux.

In essence, a browser does not support a CSS feature until it drops the vendor prefix. In essence, for border-radius, the only browsers to support it are Opera 10.50 and the upcoming Internet Explorer 9. Any other browser is just dipping their foot into the stream to test the waters.

As web developers, we make the choice to implement a design with or without vendor prefixes and their existence does not mean that we have to use them. If you consider them harmful, as PPK does, then don't use them. Rest assured that eventually all browsers will eventually come around and your CSS will remain pristine.

But we're an impatient bunch, we want to use the latest and greatest features that the browsers send our way. The price for our impatience is a few extra lines of CSS.

Dealing with Backwards Compatibility

Sadly, as CSS gets more complex, even vendor prefixes can't save us from dealing with backwards compatibility. I've lamented previously on the multiple background specification and how a background declaration ends up being declared multiple times—and vendor prefixes aren't to blame.

This is a difficult problem to solve for browser developers and I don't have any answers. The other day on Twitter I commented on how I'd love a size: 20px 50px; shortcut for specifying width and height. I said it knowing that it's too late for this. Every browser still needs a width and height declaration to be specified and we'd be left specifying width, height and size. That isn't saving me any time or effort.

As browser developers continue to add new features to the CSS specification, we will continually and increasingly have to deal with the fallout of transition. That fallout means vendor prefixes and repetitive declarations.

I predict we'll see more CSS preprocessors like SASS that take a clean file and parses it for specific scenarios, saving us from these headache of vendor prefixes and background compatibility issues.

Either way, it's a small price to pay.

Published March 22, 2010
Categorized as HTML and CSS
Short URL:


30 Comments · RSS feed
Paul Irish said on March 22, 2010

Hear hear!
It's either we go with vendor-prefixes or use css hacks to identify and smooth out browser differences.

And yah, with tools like SASS and it's less annoying every day.

Matt Wilcox said on March 22, 2010

Totally agree. I had this discussion with Kev Adamson recently. vendor prefixes are required until a final spec is out. Any seeming similarity between vendor syntax is merely happy coincidence.

Mike Taylor said on March 22, 2010

I totally agree that some form of prefix is necessary--just not totally sure what that should be. However, the notion that "a browser does not support a CSS feature until it drops the vendor prefix" is probably best left browser vendor marketing efforts. As you've already said, if we can use something as web developers and it mostly works--most of us will, prefix or not.

Kwick said on March 22, 2010

Just read both articles and agree that as web developers we are capable of making our own decisions. I agree you should not litter your CSS with an abundance of Browser Prefixes but definitely dabble with what you see fit.

Thanks, I enjoyed this article my fellow web developers argue my use of Browser prefixes and I will definitely be passing this on : )

Nathan Kunicki said on March 22, 2010

While I agree with the principle, I still have an inherent dislike towards them. There's always the risk that the browser developer decides to go with a different implementation than the current "standard", and as such border-radius might end up looking different on Opera than on Safari. What if the browser developer doesn't drop the prefix, because of a slight variation? Or just pure lazyness? We end up in a situation no different than IE's coloured scrollbars or DirectX filters.

Jason Beaird said on March 22, 2010

I'm with PPK on this one. While webkit's confusing implementation of individual border-radii provides a seemingly good defense for vendor prefixes, I would argue that they should update their implementation rather than hiding behind "experimental" prefixes. For many CSS3 declarations the implementation is consistent across multiple clients. At that point, the prefix has outlived it's purpose and has simply become a nuisance.

Zach Leatherman said on March 22, 2010

When Webkit released its border-radius support, their interpretation was essentially cemented in place. They couldn't change the behavior of their proprietary CSS property if they wanted to, because existing code is currently using it.

Of course, when they move to support the "border-radius" property without the standard prefix, then they will want to "update their implementation" while still maintaining the old way for -webkit-border-radius.

Matt Wilcox said on March 22, 2010

I'm amazed that people are arguing for the abolition of prefixes.

The point of the prefix is because there is not yet a finalised specification for achieving the required result. Heck, there might not even be a finalised concept of the required result. You can not rationally argue for writing one rule that breaks or renders differently on different browsers. Far more importantly, it's simply not practical to argue for browsers to NOT have prefixes for incomplete CSS effects.

If mozilla support a new property called, for example, css-magic, it might have a syntax of:

css-magic: on;

likewise webkit might think it's a nice idea, think of a caveat and introduce a new syntax:

css-magic: on top;

well, how can you possibly write a page that will work in both Mozilla AND webkit if there's no prefix? Any rule you write will be an invalid syntax for the "other" browser.

and then after much argument and testing the final version of the spec as put into CSS3 by the W3C might be:

css-magic: top on;

And you're now at a place where what used to work on older browsers won't work on new browsers, site's start to look broken, and you've got clients on the phone saying how their site looks worse than it did on an older browser!

People, please don't let the fortunate happenstance of current implemntations similarity across platforms make you think that "its that easy" to get to that point. The reason they're so similar NOW is because of the work that went in EARLIER, with the prefixes. Without them no concensus can be made, you can't trial different approaches to see their practical limitations and impacts, and you break the web.

Matt Wilcox said on March 22, 2010

Additionally, vendors can support the prefix version in addition to the finalised version, so that render differences can be controlled by the author.

We need predictability and stability from CSS, not continually breaking or unpredictable behaviour. Prefixes enable control, and predictability. If you want to play with bleeding edge stuff (and all of this IS bleeding edge until the W3C stamp it as official, reguardless of how solid or consistent the prefix implementations are cross-platform), pay the price by writing responsible code.

Chris Coyier said on March 22, 2010

Rabble rabble rabble! Where is the standardization!

But really... I think the interesting debate will be down the road, once the specs are done. Maybe Firefox 4 will support "border-radius" in the official spec format. Then how long do we keep using the -moz version? Maybe a year or two is my guess.

Jonathan Snook said on March 22, 2010

@Jason: that's basically the point I'm trying to make. Specs change. Another example: CSS gradients. Safari implemented them first but the spec has changed and Firefox has gone a different direction. Now that a spec has been solidified (Borders and backgrounds is now a candidate recommendation), it is the responsibility of browsers to match the spec and drop the vendor prefix. This is the way the process is designed to work.

emil said on March 22, 2010

Considering the speed of developing and finalizing web standards, the browser prefixes make perfect sense. Since when is progressive enhancement a bad thing.

Google Chrome 4 also supports border-radius, without a prefix. I bet that by the time IE9 is released, all major browsers will drop the prefix, the move forward with the border-radius property.

Jason Beaird said on March 22, 2010

I understand that many of these things are still in flux, but when we've reached the point where everything is consistent across 4 lines of CSS but the prefix, something is definitely wrong. I have no problem with prefixes for experimental implementation for testing, but vendors should not wait - even for a candidate recommendation - before dropping the prefix. My reasoning for the rush to drop them is that the longer these prefixes exist, the longer we'll have to include them in our CSS. I'd rather see an evolving, inconsistent implementation than to keep these duplicated declarations in our CSS for years to come.

Sam Sherwood said on March 22, 2010

I agree with Jason. Most of the prefixes you see in use today have nearly the exact same configuration. Browser specific prefixes are just like browser-specific 'insert anything'. Why not implement every experimental tag with a browser prefix?

Prefixes simply don't encourage conformity. That being said, I don't mind if browsers use them; as with all things, leave the choice up to the developer. Personally, I'll stick to manageable, standardized code.

Divya said on March 22, 2010

I agree with PPK in considering vendor prefixes harmful. But, what I consider more harmful is how web designers are encouraged to use it on production websites. Granted they are necessary, but web designers need to make an informed choice, instead of using them just because they are part of "CSS3". I wrote about it here

kevadamson said on March 22, 2010

I wrote this back in December:

Then Matt Wilcox slapped me up with some knowledge I'd overlooked. Basically, as he mentions above, if a browser decides to add new syntax to a rule it could break it entirely in another browser.

A secondary stage of testing would be nice though, like -beta- or something. Just to cut down on repetition. But I don't understand the process and logistics enough to know if these could happen ...

Bridget Stewart said on March 22, 2010

Just a thought...

How about organizing vendor prefixed declarations into their own stylesheet, like we do with IE fixes. The expected CSS3 implementations go into the main stylesheet. Then, you know where all your vendor prefixed things are and remove them as necessary. You might even get to ignore them for a time if the final implementation for the declaration is the same as the prefixed version. No one would know the difference, really. Remembering that browsers don't render what they don't understand, everything should be cool, shouldn't it?

Daniel said on March 22, 2010

Well, one could argue that you could mirror the W3C guidelines here. Like: if there are 2 identical implementations of a css rule, you might as well drop the prefix. But it still feels better to me, if one central organization (like the W3C) will have the last word on what will become the standard.

@Bridget: the thing is that we can't use conditional comments for all the other browsers AFAIK.

Paul said on March 22, 2010

As PKK stated:
"Originally, the point of vendor prefixes was to allow browser makers to start supporting experimental CSS declarations."

So i don't really get the problem. In the case of safari and there early implementation of -webkit-border-radius they keep the implementation as -webkit...... and make an new border-radius as accepted by W3C.

It's up to the developer if he wants to put in the effort to support all the different vendor implementations.

Let's not take away the responsibility from the developer just because he want his site/application to look fancy. Using non W3C supported/accepted features comes with consequences. Mainly extra development time, biggger and complexer files.

Bridget Stewart said on March 22, 2010


You don't need conditional comments just to put all the prefixed rules in their own stylesheet. Assuming the browser doesn't yet recognize border-radius without the prefix, it will ignore it in the main stylesheet, where it was placed unprefixed.

Instead, it will apply the prefixed version of the declaration that it understands (the one for the browser that it is).

Then as browsers implement the CSS3 official property, the one standardized declaration will do the work...depending on your stylesheet hierarchy, or once you remove the prefixed declaration. Knowing that all prefixed declarations are contained in a secondary stylesheet should make hunting them down to squash them easier to do if/when it becomes necessary.

Lars Gunther said on March 22, 2010

I echo your stance at on my blog and add a bit more detail to the argument.

I might also add that according to Douglas Crockford writing code is generally not what is taking time in development. Those extra lines are not the end of the world, just an annoyance.

Jasper said on March 22, 2010

A thought: what about both with-prefix and sans? Then designers could use whichever they want, or both, for more flexibility. The with-prefix rule would override the sans.

David Rojas said on March 23, 2010

I just noticed that border-radius works in Chrome (besides -webkit-border-radius). Weird.

Dena said on March 23, 2010

Nicely put Jonathan. Although i fear that, backwards compatibility is our worst enemy when it comes to CSS. While we still suffer the wounds that IE6 caused, i'm afraid it will be at least 5-6 years before CSS3 is fully usable in any web site. Shame... I would love to use border-radius :)

Mark Story said on March 23, 2010

I think vendor prefixes are here to stay and shouldn't leave any time soon. The room for experimentation and failure before things get standardized is an important part of software development, especially open source software of which some browsers are. Denying or trying to remove that approach is likely to muddy the waters even further.

While the differences between -webkit-gradient and -moz-linear-gradient can be confusing and annoying, things would be even worse without vendor extensions. The best part like you said is you don't have to use them. If you feel wary about non-standard properties, don't use them.

RussellUresti said on March 23, 2010

Agreed. The vendor prefix isn't doing anything to hurt web standards. People want new CSS properties to play with before the spec has been finalized, so browsers that can add them in using a vendor prefix, knowing the spec might change.

It would actually be more harmful to web standards to do away with the vendor prefixes. There are only 2 options at that point:

1) Do not give developers the ability to use or play with CSS properties that are still in spec development.

2) Implement them as their real property name (i.e. 'border-radius' as opposed to '-webkit-border-radius') and then constantly change how that property behaves every time the spec is updated.

Both of those options are silly and detrimental to web standards. Keep the prefixes. Just be aware that once the spec if finalized and approved to stop using the prefix and start using the actual property.

essay said on March 24, 2010

great site really informative i learned a lot great stuff keep it up

evision said on March 26, 2010

Shiva said on March 26, 2010

I think its most important when using vendor-prefixes, to make sure you put in the standard requirement as well. This will cover you in some cases when the vendor-prefixes are no longer necessary

An example is:
-webkit-box-shadow:10px 15px 20px #000;
-moz-box-shadow: 10px 15px 20px #000;
box-shadow:10px 15px 20px #000;

Michael Kozakewich said on March 26, 2010

I've been tinkering with a PHP framework to do some of that.
I originally designed it so one may use functions such as borderRadius() once, to set each individual vendor prefix, but now I'm thinking some sort of pre-pre-processor might be necessary. Maybe include a php file in your HTML, use a PHP function to link to the stylesheet, and then PHP goes through and adds vendor extensions where necessary.

It seems the use cases are reaching a head. One thing that seems important to me right now is stuff like using -moz-inline-stack for inline-block things in Firefox 2, and all those tiny little quirks in browsers that are still out there.

Sorry, comments are closed for this post. If you have any further questions or comments, feel free to send them to me directly.