ベンダー接頭辞は有害か
MozillaでHTML5パーサなどの開発に関わっているHenri Sivonenが、自身のWebサイトにベンダー接頭辞はWebにとって有害であるいう考察記事を公開しています。
ベンダー接頭辞はWeb開発者にも、利用者にも、そしてブラウザの競争においても有害であり、ベンダーは接頭辞つきの実装をやめるべきだという指摘を、様々な点から分析し考察しています。
利用者やブラウザの競争においても有害？
CSSのベンダー接頭辞に関する「手間」については、CSS3の機能が広く利用されているいま、説明する必要はあまりないかと思われます。
最近ではAPI仕様についても、ベンダー接頭辞をつけた実装が行われるようになりました。標準の実装において慣習となりつつあるわけです。しかし、利用者やブラウザの競争においても有害となるのはなぜでしょうか。
この背景には、とくにWebKitが挙げられるのではと考えられます。WebKitには多くの大企業が開発に関わるようになり、幅広い機能が短い期間の間に動くレベルまで実装されるようになりました。こうした新しい機能については、かなり多くのものがWebKitの接頭辞つきで実装されています。
新しい機能の多くは、短いリリースサイクルを持つChromeでいち早く利用可能になります。また、こうした新しい機能を紹介する目的で作られたデモの多くは、WebKitの接頭辞のみを利用しているため、たとえ同じ機能が別のブラウザで後に実装されたとしても、動作しません。
デモだけで済めばよいですが、モバイルでのWebKitの寡占状態によって、WebKit接頭辞つきの機能に依存したWebコンテンツは増加する一方です。その機能がなければ動かないコンテンツも増えています。
WebKitだけに限定される話ではありませんし、接頭辞つきプロパティを使うべきではないと言いたいわけではありませんが、最低限の対応は心がけたいところです。
HTML5では推奨されないベンダー接頭辞
さて、こうした接頭辞つき機能への依存もあり、他のベンダーの接頭辞も解釈するよう求めるバグ報告なども上がるケースがあります。接頭辞の導入された目的を考えると、これは受け入れがたいことです。
しかし、広く使われている機能であれば、ベンダー固有であるにせよデファクト標準に近い性質を持ちます。非標準であった機能の標準化を数多く行なっているのが、HTML5仕様です。
実は、ベンダー接頭辞の仕組みはHTML5仕様にも記されています。拡張性について書かれたセクションに、ベンダー固有拡張の属性に関して定義があります。
固有拡張の属性は、x-attributenameという形式で、先頭にx-がつきます。GoogleがChromeに実装した音声入力機能などがこの仕組みを採用し、<input x-webkit-speech>として実装されています。
ただし、HTML5仕様では「この仕様に対し、ベンダー固有のプロプライエタリな拡張は強く推奨しない」と但し書きがついた上で、拡張に関する定義がなされています。ベンダー固有拡張は詳細な挙動が仕様として公開されないこともあり、HTML5の目的である相互運用性の確保に相反することが理由として考えられます。
また、そうした拡張に依存したコンテンツが増えてしまうと、HTML5の方針である「既存コンテンツのサポート」「車輪の再発明を避ける」に従い、接頭辞つきの機能をそのまま取り入れる可能性も否定できないですから、それを避けたいとも考えられます。
CSS WGのco-chairも反対が
CSS WGにおいても、ベンダー接頭辞に反対しているメンバーが居ます。なんとWGのco-chairであるDaniel Glazmanがその一人です。先日もベンダー接頭辞に関するエントリを自身のBlogに投稿しています。
Danielは次のような提案をしています。
- 試験的な機能は安定するまでWebコンテンツではデフォルトで無効とする（アプリケーションレベルでは有効）
- デバッグメニューから有効にすることで利用可能とする
- 試験的な機能を有効にするか利用者に尋ねる機能をAPIとして用意する（有効範囲はドメイン単位）
- ブラウザーがバージョンアップしたら、いま一度無効化される
議論を広げるためにすこし大きく表現したようですが、試験的な機能の有効化については、冒頭に取り上げたHenriの記事でも「開発版に留めるべき」といった見解を示しています。
ベンダー接頭辞とつき合うにあたり
ベンダー接頭辞に関する問題提起は定期的に盛り上がりを見せますが、大きな動きになることはありません。また、ベンダー接頭辞がなくなったとしても、接頭辞つき機能との互換性を考えると、しばらくはベンダー接頭辞とつき合う必要があるでしょう。
CSSについては、昨年投稿した 「ベンダー接頭辞は使ってもよいか」というエントリで、次のような方針を紹介しています。
- 接頭辞つきプロパティを書くのであれば、正式なプロパティも含める
- 仕様の安定度や実装状況をみて、新しい機能に大きく依存しないように使う
APIに関しても、同じように考えることができるでしょう。
しかしながら、「正式なプロパティを含める」という点に関しては、うまくいかないこともあります。この点については、別に取り上げたいと思います。