本の虫さんで、「Blink、新機能に対して新たなベンダープレフィクスを追加しない決定」 という記事が上がっていた （ちなみに border-radius は現状、-moz- も -webkit- も不要で使えますよ） のですが、これ、確か Blink レンダリングエンジンが発表された時から FAQ とかに書かれていましたよね？ なので今さらだと思いますが、当 Blog では当時触れていなかったし、いい機会ですので簡単に書いてみたいと思います。
Google の Chromium プロジェクトにおいて、レンダリングエンジンを Webkit から、Webkit をフォークして開発された新しいオープンソースレンダリングエンジン 「Blink」 に切り替えますよとの発表がされたのは、今年の 4月 4日ですが、その時に Blink プロジェクトのページもあわせて公開されています。
で、該当部分は下記です。
Vendor Prefixes
Historically, browsers have relied on vendor prefixes (e.g., -webkit-feature) to ship experimental features to web developers. This approach can be harmful to compatibility because web content comes to rely upon these vendor-prefixed names. Going forward, instead of enabling a feature by default with a vendor prefix, we will instead keep the (unprefixed) feature behind the "enable experimental web platform features" flag in about:flags until the feature is ready to be enabled by default. Mozilla has already embarked on a similar policy and the W3C CSS WG formed a rough consensus around a complementary policy.
開発者向け FAQ にも下記の記述が。
Will we see a -chrome- vendor prefix now?
We've seen how the proliferation of vendor prefixes has caused pain for developers and we don't want to exacerbate this. As of today, Chrome is adopting a policy on vendor prefixes, one that is similar to Mozilla's recently announced policy.
In short: we won't use vendor prefixes for new features. Instead, we'll expose a single setting (in about:flags) to enable experimental DOM/CSS features for you to see what's coming, play around, and provide feedback, much as we do today with the "Experimental WebKit Features" flag. Only when we're ready to see these features ship to stable will they be enabled by default in the dev/canary channels.
For legacy vendor-prefixed features, we will continue to use the -webkit- prefix because renaming all these prefixes to something else would cause developers unnecessary pain. We've started looking into real world usage of HTML5 and CSS3 features and hope to use data like this to better inform how we can responsibly deprecate prefixed properties and APIs. As for any non-standard features that we inherited (like -webkit-box-reflect), over time we hope to either help standardize or deprecate them on a case-by-case basis.
「ベンダプレフィックスに -chrome- が増えるの？」 という質問に対して、
- 今後、新しい機能に対してベンダプレフィックスを増やすことはしない
- 実験的な DOM / CSS の機能に関しては、about:flags で設定可能にする
- 正式にリリースが可能になった時点で、dev/canary チャネルにおいてデフォルト有効の状態にする
- 既存の -webkit- ベンダプレフィックスは引き続き使用可能
- プレフィックス付きの記述をどのタイミングで廃止するかは、統計データを基に決める
ということで、これは、Mozilla の方針 （Re: pointerLock vendor prefixes, shims and usability / なるべくベンダプレフィックス使わないようにしようぜっていう話） 同様、また、Opera はレンダリングエンジンに Blink を採用することを発表していますので、今後は徐々にベンダプレフィックスが消えていく流れになるものと思われます。
この流れに個人的には超賛成
だってベンダプレフィックスいちいち書くのめんどくさいし。実装状況にあわせてベンダプレフィックス削除するみたいなメンテもアホらしい。最近では Firefox も Chrome も高速リリースサイクルのおかげでアップデートが早いので、新機能の先行実装から正式実装までそんなに長い間待たされることもないし。IE？ 何それ美味しいの？ Webkit は...... どうなるんでしょうね。
あと、すでに使われているベンダプレフィックスに関しても、Blink も Mozilla もサポート切っちゃって大丈夫か統計データで検証しつつみたいな感じで気をつかっているようですが、正式な実装が完了した時点でどんどんサポート切っちゃえばいいと思いますよ。
先行実装の機能を使うって選択をした時点でそのリスクは想定しておくべきだし、ベンダプレフィックスが必要なスタイルやコードを書くなら、プレフィックスなしの記述も併記しとくってのは基本ですから、それ怠って動かなくなるのは作る側の問題ですしね。極端かもしれないけど。
必ずベンダプレフィックスなしの記述を併記しましょう
ということで、ベンダプレフィックス付きのスタイルを書く場合は、必ず、プレフィックスなしの記述も併記しておきましょう。順番は、プレフィックス付き → プレフィックスなし の順です。基本的にはこれさえ忘れなければ、ほぼ問題は起きません。
.hoge {
-webkit-transform: rotate(50deg);
transform: rotate(50deg);
-webkit-transition: -webkit-transform .5s;
transition: transform .5s;
}
モバイルとかだと、先行実装の機能を使ってあれこれみたいなことも多いと思いますが、くれぐれも、「iPhone の Safari でだけ動けばいいから -webkit- 付きの記述だけでいいや」 みたいなことはしないようにしましょうね。
