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 css3please.com it's less annoying every day.

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.

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.

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 : )

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.

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.

Jason,
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.

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.

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.

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.

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.

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.

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.

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

I wrote this back in December:
http://kevadamson.com/talking-of-design/article/single-css-testing-prefix

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 ...

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?

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.

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.

@Daniel

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.

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.

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.

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

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 :)

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.

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.

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

www.onlineuniversalwork.com

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;

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.