@Alex: Yes, I’m angry on this matter. And reading your article actually made me angrier, especially the “Don’t trust the impletors, don’t trust the spec editor, listen to me instead” part at the end. Sometimes, being angry leads me to write hard words (especially in English since I’m not native English speaker and I find it difficult to express nuances).
I hope it doesn’t hide the fact that more than 75% of the prefixed properties used on the web today are -webkit- ones and they have often no equivalent prefix for other browsers (meaning only webkit browsers can understand them, like in the old “IE-optimized” days).
If those properties are useful (which they usually are) but are used widely on the web using a -webkit- prefix, I have to conclude that either (1) they were not ready to be used in production,(2) webkit devs didn’t gave enough time to other UA to understand and comment the spec before shipping in RTM or (3) the property is stable enough and should have shipped prefix-free.
In those cases, I don’t see any other culprit for the prefix mess than the browser vendor that made misuse (intentionnaly or not) of them and has put other browser vendors and web authors in difficulty (using the webkit prefix or don’t use the property).
To many, the response to this problem is simply to ship experimental properties in experimental builds only (with a prefix or not, I don’t mind), and ships in RTM builds when either (1) the spec has reached a consensus or (2) the spec will never get a consensus anytime soon but the feature is considered as needed by the implementor.
Shipping in an RTM browser a prefixed property while the standardisation is in progress is a mistake. I would prefer an unprefixed property that support only cases that are known as stable enough.
