If we allowed the W3C to become a bottleneck like you propose rather than a seal of approval like it is in practice, we wouldn't have CSS transitions in any bro

If we allowed the W3C to become a bottleneck like you propose rather than a seal of approval like it is in practice, we wouldn't have CSS transitions in any browser this decade, we wouldn't have AJAX, we wouldn't have canvas, etc. It would be really nice if things could work the way you want, but history has shown time and again that if progress in Web standards is going to proceed at a reasonable pace, it is almost always implemented as a proof-of-concept and then standardized once its utility is recognized. This back-and-forth between shipping code and the standards bodies has evolved as part of the process. And contrary to your claim that prefixes are just applied blindly, some CSS features have indeed been implemented differently by different browsers — gradients and the flexible box model, to name just a couple. Prefixing is the only reliable way to get the feature before the W3C actually produces a standard with it 10-15 years down the road (I wish that was hyperbole, but it isn't — just look at how long they plugged away at XHTML 2 with no end in sight before everybody got tired of waiting and started implementing HTML5). The point of prefixes is to ensure that the W3C are never faced with a choice between standardizing a CSS feature against their will and breaking the Web. Although I don't like the bloat from an ideological standpoint, in practice this is the best way we've come up with. But to make reading, writing and maintenance easier, I generally like using a CSS metalanguage with a library like SASS+Compass or Stylus+Nib. That way, you can just write, say, "transition: color .5s linear" and it'll get translated into the appropriate cross-browser code.