そんなことをCSS WGのco-chairが言うってのが面白いですね。
I said it in the past and I maintain my opinion: the vendor prefixes as we manage them in CSS don't make sense.
vendor prefixes considered harmful (was: vendor prefix properties diverging from official properties)
「HTML5はまだWD段階なのに、vendor prefixみたいな仕組みもなく要素や属性が使われてるけどどうよ？」といった感じでしょうか。HTML5については、そういう仕組みがHTMLにないというのが大きな理由な気がしますが、うーん。
まあそれはおいといて、いわゆる(？)「-moz-prop -webkit-prop -o-prop って書くのだるい」問題については、あまりいい状況になってないわけです。
とりあえず、vendor prefixについておさらいすることからはじめましょうか。目的は、大きく分けてふたつ。
後者についてはprefixをつけるのが妥当でしょうが、前者はどうでしょうか。
つけることの利点は、仕様が安定していない状態から実装できることにあるでしょう。Authors should avoid vendor-specific extensions.*
とありますから、後で仕様が変更してもそれは仕方ないと言えるわけです。仕様の変更は border-radiusのサブプロパティやグラデーションなどですでに起こっているので、リスク回避として有効かなと。
しかし、ひとたび仕様が安定し実装が増えてくると、やつらはとたんに面倒なものになってしまいます。prefixは仕様がCRになると落とせるのですが、個々のプロパティではなく仕様全体のステータスに依存するので、安定度が機能毎に異なると面倒なことになるわけです。
この話、去年の5月にもでています。
「Mozillaも-webkit-propを実装すべきか」っていうところから始まるスレッドなんですが、その中で -wd-prop みたく、実験的であることを示す印に一本化するのはどうかという提案が出ています。
なるほど、こうすると書き手や互換性のテストでの手間が減ってよいかもしれません。ただ、問題もあります。
というわけで、同じ書き方でも解釈に違いが出てくる可能性があるわけです。ただ、名前が共通してしまう分「試験実装だし問題ないだろ」と言いにくくなる感じがしますね。結局のところ試験実装であろうとなかろうと、新しい機能を手間なく使いたいという要求の方が強いでしょうから。それなら、prefixそもそも要らなくなるよねっていう話にもなりますし。
結局は I think that is the real problem: we're too slow.*
ってことなのかなと。仕様と実装のコントロールができていれば、大きな問題にはならないはずなので。
で、現時点で出来ることは、プロパティに関して実装状況を各ベンダーが共有して、prefixを落とすタイミングをはかるくらいでしょうか。こちらは下旬にF2Fがあるので、そこでちょっと話されるようです。
とはいえ、こういった状態になってるのも、実装と仕様の両方が進んでいることのあらわれなんですけどね。そう考えるのはポジティブ過ぎるかなあ。