However, there is a counter point, and a commenter to his post makes it:

Some properties do change. WebKit’s gradient syntax is disgusting and -moz one is much more humane.

To me, the core problem is the rigid “vendor prefix until standardized”. Instead, I would much prefer the browser to try to do the right thing. If you see box-sizing: border-box; only, use that…. and -vendor-* takes precedent. This also allows the following pattern: Say Mozilla invents a cool new feature as use-css: awesome; the WebKit guys can say “actually, that is great, I will copy that” and support it as is (and also map -webkit-use-css if they fancy.

The -x-* thoughts don’t make as much sense to me as the problem is when browsers differ from each other :)

I want to see browser vendors combining their efforts in a single CSS engine which they all use and is extensible for their own vendor specific sugar. It’s insane that they STILL chisel away in their own corners. To me thats the biggest failure in pushing standards.
.
Same can be said about the JS engine and HTML5 engine, each vendor wastes money and time on creating their OWN implementation.
.
Give me one VIABLE reason why browser vendors should not work together on browser standards implementations.

One valid reason: innovation is best encouraged in independent groups.

Instead of vendor prefixes, just have a standard non-standard prefix that catches all of them. -*-transition-property. If the vendors differ from the first vendor to implement that, add their own versions.

People like to complain too much. Does it break dry? Yes. Does it make sense? Yes. If you’re that worried about dry, use a templating language on your css. Poof, you now have an abstraction layer on your css. You can all of a sudden do math, use variables for colors, and make your prefix styles one liners. And if something changes, you just have to change it in one place.

Sorry Dion, but that’s a terrible suggestion. The risk is that different vendors might implement things differently. Today that’s easy to accommodate since every vendor have their own prefix. Without prefixes, all bets are off …

As Microsoft showed in a recent blog, while browsers do have support for rounding corners using border-radius every browser does actually render it differently. Given that every browser is doing their own thing right now and no two browsers are the same I support the fact that Webkit and Mozilla still require the vendor prefix.

The next obvious example is the one everyone has mentioned in regards to gradients. While a great idea, if you’re the type that wants a gradient on say the first 100 px and then a solid color after that and you don’t know the exact height (or width depending on your gradient) then you are SOL with the Webkit version. That’s why I have given up using it.

Not sure what ppk is thinking these days, calling vendor prefixes harmful is just stupid. There will always be unfinished standards where it makes sense to have them. Guess he just got lazy and figured he could save a few characters, turning the web into an experimental mess in the process. I’ll take his rants with a grain of salt. Maybe taking things way too far is just his way of stirring things up? It seems to be working for him.

Yes – please mr Browser Vendor. Can I have my CSS3 without prefixes, pretty please?
.
I’m sure I’m repeating myself (and some other people) when I say this; W3C should provide working code that implements their “recommendations” (they’re aren’t actually standards you know).
.
As every browser maker tries to get their heads around the recommendations and how to interpret them a lot is (potentially) lost in translation – resulting in headaches for everyone. Varying implementations of border-radius is just one example.
.
Or maybe I’m just oblivious to how the W3c works and they actually _have_ live code implementing their own medicine?

I definitely have to agree with the general consensus here – no offense to PPK, but that’s a strong statement that doesn’t seem to have been properly vetted. Most of the -vendor-xxx prefixes exist for properties that are “standardized”, but don’t have working specifications yet. Others aren’t even intended to be ever standardized. Prefixing these properties is an effective way to sandbox them while the implementation is still evolving. Not doing so would be disastrous to any web page that dared use them. One could argue that the properties shouldn’t be exposed at all until they are sufficiently spec’d out, but…. well, I want to use border-radius sometime in the next decade.

It’s not innovation, it’s just my Safari is longer than your Firefox wich is bigger than your Chrome. I work in the web since 1995 and I’m really tired of all that bullshit. Same old story, browsers war again. I can’t understand that people don’t remember anything and continue to make things rapidly implemented, buggy, with differents behaviors.

@genericallyloud You said exactly what I was thinking.
.
Raw CSS violates DRY. There’s no way to not repeat yourself, unless you generate your CSS. Adding vendor-specific prefixes only adds to this issue, it doesn’t create it.
.
It would be awful if all the vendors polluted the CSS namespace with their proprietary extensions – I think they’ve handled the issue responsibly.

I think that this frustration is the product of a misunderstanding of the purpose of the vendor prefixes. The vendor prefixes are used for properties and values which are not formalized and finalized; that is, properties and values which are, by definition, in flux. Using vendor prefixes allows vendors to adopt one of a set of conflicting proto-standards, and provide working (if flawed) new features and a means to fall back where implementations differ. It also provides a clear line where developers can know which features are unstable, and avoid them if they choose. With that in mind, the prefixes are not only necessary but a good step toward mitigating the problems that arose during the “browser wars” where Netscape and Microsoft polluted the web with an endless stream of bugs.
.
The real problem with vendor prefixes is that they don’t allow for falling back between different versions of a single vendor’s product: if WebKit developers agree that Mozilla’s gradient implementation is more humane, they are forced to either:
.
1. break existing code using the current WebKit spec, by introducing a different spec using the same vendor-prefixed code;
2. introduce versioning, and thus complication, within their vendor prefix;
3. make a bet that Mozilla’s implementation will be adopted (more or less) as the final standard, and pollute the global grammar prematurely;
4. determine on the fly which spec is being used (which may not be possible); or,
5. do nothing and stick with a subpar spec.
.
I don’t think this is sustainable. And alternatives are not very attractive. This is just a weakness of an ever-evolving platform with multiple, competing APIs. But the alternatives to that are not very attractive either. It might be that where we are is the best of a bunch of bad choices. Maybe some small improvements could be made, but I’m afraid any improvement here risks further fragmenting development and further damaging DRY.
.
It’s worth noting, though, that this weakness with vendor prefixes applies to standard CSS too. But thankfully all of the major vendors are relegating their known moving targets to vendor-prefixed spaces.
.
I also want to address some of what others have said here:
.
BenGerrisen,

I want to see browser vendors combining their efforts in a single CSS engine which they all use and is extensible for their own vendor specific sugar. It’s insane that they STILL chisel away in their own corners. To me thats the biggest failure in pushing standards.

I don’t think the recent history of standards advancement supports your position. Much of what we’re looking forward to in CSS3 and HTML5 is a product of these sorts of vendor innovations. Expecting browser vendors to cooperate before introducing new features may very well mean no new features are ever introduced. It would give each vendor complete veto power on every minute detail, whereas today each vendor is more or less expected to follow the thrust of where the majority of other vendors are coalescing. It’s imperfect in the process, but the result is more room for innovation with some sanity checks. You can still avoid using unstable features by avoiding anything with a vendor prefix.

Except it’s precisely what’s pushed standards forward so much in recent years. It’s exactly why we have properties like border-radius and tags like canvas. The process, as it exists today, has dragged even Microsoft kicking and screaming into building a modern browser—which many, including me, had already written off as not bloody likely. The alternative gave us dead-in-the-water standards like XHTML2, which would have really, truly, wasted time, money and resources.
* * *
genericallyloud,
A templating language won’t necessarily be able to account for every divergent implementation.
* * *
AngusC,
No, that is the ideal the web development community should be striving for.
* * *
ThomasHansen,
As I said above, that is only easy until a single vendor’s product diverges between versions.
* * *
blepore,

While a great idea, if you’re the type that wants a gradient on say the first 100 px and then a solid color after that and you don’t know the exact height (or width depending on your gradient) then you are SOL with the Webkit version.

You can use the -webkit-background-size property.
* * *
rasmusfl0e,

W3C should provide working code that implements their “recommendations”

That would be, to put it lightly, sublime. It would, at the very least, provide a reference point where each vendor could look if the specification is ambiguous.

(they’re aren’t actually standards you know)

You be pedantic, I’ll be pedantic. Of course they’re standards. There is no “standard” for determining whether or not a specification is a “standard” or not besides the deference of those implementing the specification. In the case of W3, those specifications which have gained the deference of browser vendors are standards. Those which haven’t (eg XHTML2) are, of course, not.

Varying implementations of border-radius is just one example.

It’s worth noting, here, that CSS3 is neither “recommended” nor strictly deferred to by vendors. It has not yet reached a state of being a standard. So the differences in border-radius implementations are not an example of a problem with finalized W3 specifications.
* * *
jmar777,

One could argue that the properties shouldn’t be exposed at all until they are sufficiently spec’d out

But they should (and I realize you’re not actually arguing for this, but I want to address it anyway). Exposing them, and allowing developers to interact with them, is crucial—especially given the way web standards evolve—as a sanity check against any new feature’s implementation.
.
Much of what’s wrong with existing web standards is a product of that kind of opacity in specification. In other words, if developers had been given access to evolving CSS implementations early on, we would not have waited years for relatively poor solutions to asinine problems like rounded corners, box alignment, layout and so on. All of these features would have been implemented sooner and better, due to pressure from those consuming the specifications—pressure that was diverted much earlier as the foundation of the specifications was solidified before this kind of experimental web feature development was around.
* * *
fpiat,
That’s precisely what vendor prefixes solve. They are a direct response to the nightmare of the original “browser wars”. If you don’t want to muck about with unstable features, it’s as simple as skipping anything with a vendor prefix.

The way it exists currently lets the web developer understand when they are using vendor specific functionality that may not be portable or that may differ in its implementation. I think this is the only reasonable solution. Worst case scenario is when a vendor creates vendor specific tags that *aren’t* branded as such because you now have a dependency you might not have been aware of. I don’t see convenience, I see dishonest vendor lock-in.

Even when the spec is finalized vendor specific prefixes should stay for backwards compatibility for the early adopters and aliased to the standard tag. As a plus, this would also allow the vendor to deviate from the standard for their own ‘value add’ variant.

As pointed out, things like border-radius and gradients are implemented differently on webkit and mozilla so they need the prefixes. (Incidentally, why the heck is it border radius and not corner radius?)

What does need to happen is for the W3C to move faster. Why the heck is it taking so long to standardize border-radius? Most normal browsers (read not IE) had them for years.
On top of that, given our obsession with gradients in our web design, hurrying up the gradient spec would do so much to lighten the image load of websites. But definitely go with mozilla’s implementation, webkit’s is twice as verbose and three times as confusing.

I don’t much care, to be honest. So you repeat the same style a few different ways? So what? Aren’t we all gzipping our stylesheets anyway? I remain to be convinced by this article that there’s a genuine problem here, other than an aesthetic one.

The prefixes are an eyesore, a codesmell, plain and simple. They lead to redundancy, complexity and ultimately make things harder to maintain down the road. The article is largely correct in this regard.

However… are they *necessary* at the present time? Yes. Are they the best solution to a larger problem? Very likely. Would the world be better off without them? Probably not, assuming nothing else changed to compensate.

So long as they are always a transitional thing, meaning as the specifications solidify and get implemented by the vendors then they start to go away, then that’s not so bad IMO. I wish we didn’t even have to have that be the case, but it’s not really the end of the world either I’d say and does serve a purpose.

It’s kind of like paying taxes… nobody really likes it, but we *do* derive some benefit from it, so even though it’s distasteful to many, you do it and understand why. Same here. Now, if only taxes were transitional… and no death, does not count! LOL

@eyelidlessness – I guess it depends on what your requirements of a complete solution are. As long as all of the information required to output the separate styles is provided to the template engine (or can be derived from the inputs) there should never be the problem. For rules that are exactly the same, you would supply some pretty simple arguments, for very different rules, you might have to do a little more work, but likely less than doing them all out by hand.

One can minimize DRY by not repeating yourself. First define good base classes ONCE.

.round_corners {
…
}

Once defined, why is it even still an issue. Allowing vendors to skirt around the issue of non-standard css properties in this manner is a good thing. This allows for experimentation and reduces collisions between vendors. Not every browser implements the standard the same way.

People adopting these custom NON-STANDARD properties into their work is risky. Always has been, will always be. What I want to know is when did people start thinking differently?

@justinnt If states like :hover, :focus, etc. belong in CSS, then so do transitions.

Personally, I like the vendor prefixes. They aren’t perfect but there’s a lot more good in them than bad.

The real problem is CSS itself. It’s broken and it’s getting brokener. Look, rounded corners were popular but required a lot of extra little images so it was thrown into css. Drop shadows were popular but required a lot of extra little images so they were thrown into css. Gradients were popular but required some extra images so they were thrown into css. All of this seems good on the surface but what next? Every design element that becomes popular will be thrown into css? The comment boxes on this page have a little arrow pointing to the byline, let’s have a css property for that!

What is needed is a more sophisticated, systematic approach to these things. I’d like to see an Advanced Style Sheet language that’s closer to a programming language. If done right, it would have a lot more power and flexibility and not require vendors to toss in new junk to solve specific problems. Oh, and unlike CSS, ASS would be an acronym.

I’ve thought about this a lot, and I have to say, I think that vendor extensions definitely have to be at least tweaked. I think one of the most comprehensive solutions would be that “-vendor-propertyname” applies to all CSS properties and always overrides a generic “propertyname” for a rule with the same specificity. In other words, for any property, regardless of whether it’s experimental or a well established standard, “-vendor-” can target it. Ideally, this would be used rarely, in cases where one browser’s implementation differs from anothers.

However, that’s probably going to be abused, both by developers and by browser makers. Browser makers would just extend the “-vendor-” convention into “-vendor-version-“, “-vendor-version-renderingmode-“, etc. THen they’ll create make some property behave differently when applied via “-vendor-propertyname” vs. “propertyname”. And developers would use it to hack like crazy.

OK, so maybe just apply it to experimental features, knowing you can usually just use “propertyname” instead of “-vendor-propertyname”. That’s better, and the “-vendor-propertyname” still exists when browsers offer differing implementations.

But let’s consider just nuking them for a second. Yeah, we’re forced into situations where differing implementations will compete. Yeah, that gives incredible power to the first vendor to implement a proposed extension. Yeah, it’s going to cause some headaches.

But it’s simple. It’s very simple. It cannot be abused. It forces browser vendors to communicate, to propose openly and early, to craft the most easily understood spec. And no one will ever have to go back and change their code because the “-vendor-propertyname” has been deprecated. It makes CSS easier to write and easier to read.

Frankly, I’m on board with all three solutions, they’re all better than the current situation. The only part that’s vitally important is that no developer should ever have to include a vendor prefix. But if I had to choose, then I’m going to side with simplicity. As much as the flexibility of the first two options appeals to me, the simplicity of the third option forces everyone to be as forward looking as possible, and that’s a good thing.

okonomiyaki: not sure what you mean. transitions are not states.
I’m not talking about purity, just utility :
while I do find myself using straight :hover,
whenever I want a css transition, I seem to want script hooks on it anyway, either on commencement, at each step or on callback,
and so I don’t bother declaring a css transition …

@justinnt Transitions are not states but they do define how you get from one state to another. Think about it like this: there is a default transition, it is 0 seconds linear. We should be able to change that to anything we like.

I agree that we need more scriptable control over those kinds of things, maybe some events like onTransitionStart, onTransitionEnd, etc. But basically, as you said, when you need something like that, you can do it all in script. The question is, should you have to go to that trouble when all you want is to fade from one color to another? Having different ways to accomplish the same thing doesn’t hurt.

I’m in favor of removing the browser prefixes, but there should be a catch. As a webdeveloper you need to specify that you deliberately want to use a technology that is unfinished.
.
Why not start off your CSS-file with something like:
.
@experimental “true”;
.
Which results in the browser understanding that it should, in fact, use “-moz-box-shadow” where you specified “box-shadow”.
.
Alternatively, use this instead: @experimental “2010-03-23”; to specify that the browser should use the implementation of experimental rules at and before the date specified. That way it’ll always look the same until you either remove or update the timestamp.
.
But that’s all too late now anyway, so whatever. I’ll just keep using browser-specific stylesheets using @import, which only contain style definitions that use that browser’s unique prefix.

“If you don’t like prefixes, then wait until the implementation is stable before you use it. Problem solved.”
.
Exactly right. If you want to live on the bleeding edge then this is the price you pay. If you want stable, well defined and predictable results/APIs, stick to established standards. Know the consequences of your design choices and decide if the trade offs are worth it or not.

I agree with the stance that if you truly believe in standards, then don’t use non-standard CSS properties. They aren’t cross-browser compatible, so why use them at all if you are preaching standards?

I also agree that CSS inherently violates DRY, unless you are generating it dynamically or using a templating language for it. Talking about browser vendor prefixed properties violating DRY is then a moot point.

Ok, after reading more on the subject (lots of responses all over the web), PPK’s real complaint is “CSS Standards and/or Implementation is going too slow”. Vendor prefixes are non-standard (duh) and mostly experimental, prefixes should remain and devs should use them at their own risk.

@Onderhond – leaving them out of official releases would make them pretty much useless. Even though they are not available exactly the same way, or on all browsers, people are finding real uses for this now in the wild. For example, when building apps for iphone or other mobile devices, or even just graceful degradation. Maybe everything but IE get a drop shadow. That doesn’t break the app, it just doesn’t look as pretty. Lacking support for IE is one thing. You can get pretty far depending on your audience with that. But expecting an end user to have a nightly is pretty extreme. You would really only be able to use is for playing around, which doesn’t help anyone.