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:
view plainprint?

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:

Experimental properties are often implemented in the webkit engine first and there’s no guarantee they’ll be replicated in other browsers.
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.
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 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.