I agree with most of what he says (not least the 'more free phones for mobile web developers' bit) but I think he - and, come to think of it the CSS WG - are missing some subtleties around vendor prefixes. There are three (arguably four) different uses for them
- They're a way for vendors to extend and experiment with features that don't exist in other browsers or in the standards. This is the core of the controversial bit: used one way you end up with browser lock and a recurrence of the browser wars (for the record, I enjoyed the browser wars, the problem was the wrong side won); used another way and you have a genuine tool for open experimentation. Sometimes both things will be true at the same time.
- They're a way for browser vendors to experiment with features that are under discussion by the W3C, but without a clear standard. Hence the two incompatible versions of background gradients used by WebKit and Mozilla.
- They're a way for browser vendors to implement things the W3C has solidified but for some reason hasn't ratified yet. This lassitude in actually delivering standards is the reason for Dave Balmer's "call to inaction" rant
ppk's solution: cross-implement the -webkit- prefix and create a new -beta- prefix to allow experimentation. This only solves 3 completely, and 2 so long as you're willing to accept shonky browser detection if implementations differ. I think there's a legitimate place for 1: innovation in web standards comes overwhelmingly from the browser vendors (who of course don't always act altruistically) and that needs a sensible, namespaced way of closing it off from the rest of the web.
Most importantly, if the vendors just cross implement -webkit- then we've reinvented the almighty cock-up that is the user-agent string, where every browser starts by announcing it's Netscape. That would be a suboptimal legacy.