2010-03-23

QuirksBlog: CSSベンダープレフィクスは邪悪だ

QuirksBlog: CSS vendor prefixes considered harmful

先日、IEチームのborder-radiusに関する記事を読んだ。IE9は、border-radiusをサポートする(スゲェ!)そうだし、ベンダープレフィクスはつけないそうだ(かっけー!)

記事曰く、

多くのページが、既にこの機能を用いているが、いくつかは、(省略)、IE9やOpera 10.50では、うまく描画されない。なぜならば、プレフィクスなしのborder-radiusプロパティが、使われていないからだ。

規格が、「推奨」状態に近づくにつれ、ブラウザベンダーは、実装を煮詰めてテストを繰り返し、W3Cに意見を出す。新しいコンテンツは、border-radiusに、ベンダープレフィクスを使わないよう、我々として、強く推奨するものである。

俺としては、さらに一歩を推し進めたいね。

いい加減、ベンダープレフィクスは、廃止するべきだ。こいつは、本来、存在しない問題を解決しようとしているようなものだし、Web標準にとって、害悪だ

ベンダープレフィクスは、Web開発者をして、スタイルシートをより冗長にさせるのみならず、ベンダープレフィクスを付け忘れるという、本末転倒のリスクすら生み出すのだ。

だいたい、たったひとつの効果をだすのに、なんで複数の宣言が必要なんだよ。Web標準ってのは、そういうのを防ぐためにあるんじゃないのか?

テメーら、さっさとクソみそなベンダープレフィクスとやめやがれ。いい加減にしろ、もうたくさんだ。このド低脳がッ!

論点

本来、ベンダープレフィクスの目的は、ブラウザが、実験的なCSSを実装できるようにするためのものだった。

たとえばだな。W3Cワーキンググループは、grid宣言を考案している。これは、そんなに悪いアイディアじゃあない。んで、誰かがドラフト規格を作ったとしよう。でも、ある者は、一部の詳細に、反対していたとする。つまり、規格化には、時間がかかるのだ。

で、今仮に、マイクロソフトが、現在のgridの提案に従って、実験的な実装を試みたとしよう。現時点では、マイクロソフトは、規格が変わらないかどうか、定かではないわけだ。そういうわけで、CSSにgridを付け加えるのではなく、-ms-gridを付け加える。

訳注:つまり、これによって、規格が変更されることによる、互換性の問題を回避できる。

とまあ、ここまでは、悪くない考えだ。だが、これは実際、何の役にも立たなかった。実際、もうこんなのは、要らないのだ。現実的に考えても、思想としてもだ。

現実的な問題

まあ、現実的な例というものを見てみよう。

box-sizing

ベンダープレフィクスがクソみそになってる例のひとつってのが、box-sizingプロパティだ。これは、box modelを変更できる機能なんだがな。現時点では、IE8とOperaが、box-sizingを、プレフィクスなしでサポートしている。だが、Firefoxは、-moz-box-sizingしかサポートしてやがらねぇし、SafariやChrome、それとモバイルWebkitは、-webkit-box-sizingしかサポートしてねーんだ。

div.borderbox {
    box-sizing: border-box;                       /* one */
    -moz-box-sizing: border-box;              /* two */
    -webkit-box-sizing: border-box;          /* three */
}

ひとつの効果を出すために、みっつもの宣言を使わなきゃならんのは、あまりにも馬鹿げてる。ブラウザ戦争の再来か? 標準? なにそれおいしいの?

ここでの問題点は、box-sizingは、これ以上、変わりようがないってことだ。目的は、box modelの変更だし、その値である、border-boxとcontent-boxは、どこでもサポートされてる。

この宣言は、非常に単純明快だし、すべてのブラウザで、この通りにサポートされている。だったら、すべてのブラウザで、同じ名前であってしかるべきだろ。

W3Cが認可のハンコ付くまで、プレフィクスを外すのをボケーっと待ってるつもりか? それにゃ、あと5年か10年はかかるぜ、ドアホが。

Mozilla、Webkit、お前らド低脳とちゃうか? さっさとベンダープレフィクス消しやがれダボが!

transition

Safariの追加したtransitionについて。-webkit-プレフィクスをつけにゃならん。Safariチームは、これらの宣言の機能を、明確に定義している。これ以上、もう変わりようがないのだ。

GoogleとOperaも、transitionを実装している。俺は、AppleOperaのドキュメントを見てみたが、いずれも、非常に良く似ている。実際、俺が思うに、OperaはAppleのtransitionをパクったと言っていい。

しかしながら、Appleは、-webkit-transitionを使っていて、Operaは、-o-transitionを使っている。

テメーら・・・

div.coolEffect {
  -webkit-transition-property: opacity;    /* one */
  -webkit-transition-duration: 2s;
  -o-transition-property: opacity;        /* two */
  -o-transition-duration: 2s;
  -moz-transition-property: opacity;          /* three */
  -moz-transition-duration: 2s;
  -ms-transition-property: opacity;        /* four */
  -ms-transition-duration: 2s;
}

なんで、たったひとつの効果を出すのに、四つもの宣言を使わなきゃならねーんだ。てめーら、頭脳がマヌケか? この手のアホくさいベンダープレフィクスを回避するために、Web規格があるのだろうがよ。わざとバラバラになってどうするってんだ?

Web開発者が、たまたま、ベンダープレフィクスをつけ忘れたら、どうなる? 本来動くべき効果が、動かないじゃないか。それは、標準規格が存在しない世界の話だぜ。少なくとも、俺らの話じゃねーよな? な?

いい加減にしろよ。ベンダープレフィクス爆発しろ。

未来への遺産

もっともアホくさい例は、モバイル環境にある。Operaは、タッチスクリーン メディア クエリーを、ボーダフォン ウィジェット マネージャーに実装している。-o-touchscreenだ。

後に、サムソンがWebkitベースのウィジェット マネージャーに取り掛かった時、このメディア クエリーの存在に気がついて、そっくりそのままパクった。それも、文字通りの意味でだ。

そんなわけで、今、-o-touchscreenに反応するWebkitブラウザがあるわけだ。

これは単なる始まりに過ぎないんだぜ。問題は、ますます悪くなるばかりだ。

実際、多くのサイトが、-webkit-transitionだけをつかっていて、-o-transitionを使っていない。とするとだな、Operaは、-webkit-transitionもサポートするべきなのか?

互換性という点から考えると、当然、サポートするべきだ。互換性を抜きにすると、アホの極みというしかないんだがな、これが。もっと単純な解決方法があるんだぜ。transitionは、Webのデファクトスタンダードになってるわけだ。だったら、最初から、ひとつにすりゃいいじゃねーか。

テメーら、さっさとベンダープレフィクスをやめやがれ、こんちくしょう。

思想的な問題

というわけで、現実的な視点からみると、ベンダープレフィクスは、単にバラバラになっただけだ。思想的な視点からみても、同様に、本来存在しないはずの問題を解決しているわけだ。

つまりだ。ベンダープレフィクスっていうのは、二つの問題を解決しようとしていたわけだ。

  1. すでに述べた、まだ完成していない標準に対する問題
  2. その問題に対する、根本的な問題。ブラウザベンダーが、他のブラウザの実装を気にせず、自由に自分の実装を始められるようにすること

俺が思うに、どちらの問題も、すでに解決されている。

現在、二つのブラウザで実装されている機能は、自動的に、標準になるという状況になっている。W3Cは、まだこの規格化のプロセスを受け入れていない(たぶん、一世代待つ必要があるだろう)が、実際、これは事実である。

この仕組みが動く理由というのは、今や、ブラウザベンダーは、お互いの実装をパクり合おうとしているからだ。Microsoft、Mozilla、Apple、Google、Operaは、お互いに、他社のブラウザを観察して、お互いを、標準として認めている。競争しているのは、パフォーマンスや、小奇麗なUIや、標準に対する拡張機能だ。

ベンダープレフィクスが制定された時代、つまり、ブラウザ戦争が起きていた時代とは変わって、現代では、ブラウザベンダー達は、移植性を気にしている。もはや、彼らが荒れ狂う恐れはないし、box-sizing: border-boxの意味が、「borderの内側の何か」に変わることは、あり得ない。そのような事は、現代では、まともではなくなっているのだ。

Safariチームは、クールなtransition機能を発明した。彼らは、CSSベースで実装し、ドキュメントを書き、W3Cに提出した。これは、素晴らしいことだ。

そして、彼らは、-webkit-プレフィクスを追加した。クソだ。

さて、今、Operaがやってきて、transitionをサポートしたいと考えている。Operaは、独自機能を発明するのか? Operaは急に、現在のSafariのとは全く異なる、互換性の全然ない別のtransitionを実装するのか?

そんなことが起こるはずがない。Operaの連中はバカではない。彼らは、互換性の重要性を、十分に承知している。他のブラウザベンダーも、皆同じだ。

しかしながら、彼らは独自のベンダープレフィクスを付け加える。暗愚の極みにあらずや?

transitionや、その他諸々は、すべて、デファクトスタンダードになっている。どのブラウザも、transitionを実装する際には、Safariと互換性があるようにする。誰がベンダープレフィクスなんて必要としているんだ?

ブラウザベンダー各位。貴君らは、Web標準や、他の競合相手と、協力して動いていることを、もっと誇りに思うべきであると、小生は信ずる。もはや、貴君らにベンダープレフィクスは必要ないのである。貴君らは、その境地におらざればなり。

ベンダープレフィクスを廃止するの時は来たれり。もはや、ベンダープレフィクスは、かつての過ぎ去りし時代の遺物なるのみ。さりながら、Web標準に対する、大いなる障碍となり得んことを恐る。

今回は、本の虫: QuirksBlog: HTML5のドラッグ&ドロップはクソだのように、Fで始まる四文字言葉こそ使っていないものの、文章には、明らかに、怒りといらだちを感じる。そこで、行間を読んで、そのようなニュアンスを、正しく、翻訳した。

ちなみに、リンク先のIE team blogの、border-radiusに関する記事は、秀逸なので、是非とも読むべきである。

また、この記事を受けて、当ブログのCSSから、ベンダープレフィクスを取り除いた。これにより、一時的に、FirefoxやSafariで、border-radiusが、動かなくなる。しかし、それは、いまだにベンダープレフィクスを使っている、前時代的なクソブラウザを使っている人間と、そのブラウザベンダーが悪いのであって、私のせいではない。

かの、QuirksMode - for all your browser quirksのPeter-Paul Kochが、ここに、こうして文章を公開したのである。いやしくもWebに携わる者で、彼の名前とWebサイトを知らない者は、モグリである。これに従わないブラウザベンダーのブラウザは、使う価値がない。

ちなみに、たまに批判がある、私のブログの、IEチェックであるが、IE9が、なかなか良さそうなので、IE9の発表の当日に、コードを変更した。今のコードでは、IE9以降は、警告文が表示されないはずである。もっとも、私はまだ、IE9 previewを試していない。IE9が実際にリリースされて、やはり、ダメであったなら、IEチェックは、IE9も含めるだろう。

8 comments:

  1. (PPK さんのところのコメントにも書いてありますが)「この仕組みが動く理由というのは、今や、ブラウザベンダーは、お互いの実装をパクり合おうとしているからだ。」というのは初期段階ではあてはまりません。-webkit-border-top-left-radius と -moz-border-radius-topleft や -webkit-gradient と -moz-linear-gradient の違いを見れば分かる通り、各ベンダーが「ぼくのかんがえたさいきょうの実装」を作ってるのは明らかです。
    僕としては prefix がウェブで一般的になるのは抵抗がありますが、一概にクソだとは思わないです。実装が無ければ仕様を勧告しないという方針を取っている限り必要悪では。仕様がほぼ決まり次第各ベンダーは prefix なしのバージョンに切り替えてほしいと思っています。

    関連スレッドを挙げときます。
    http://lists.w3.org/Archives/Public/www-style/2010Feb/thread.html#msg235
    http://lists.w3.org/Archives/Public/www-style/2010Mar/thread.html#msg15
    http://lists.w3.org/Archives/Public/www-style/2010Mar/thread.html#msg26
    http://lists.w3.org/Archives/Public/www-style/2010Mar/thread.html#msg298

    ReplyDelete
  2. でも、もうこの2010年では、いきなり、「何のドキュメントも書かずに、次のリリースでいきなり新機能が登場」、なんてことは、あり得ないわけです。
    それに、たとえ機能に変更があったとしても、一介のWeb開発者ごときが、どうするというのです?
    一度書かれたコードは、自動的に書き換わったりしません。
    人間が書きなおさない限り、ずっとそのままです。
    ベンダープレフィクスがあろうとなかろうと、互換性の問題は、どうしようもないのです。

    ReplyDelete
  3. -moz-プレフィックスの付いたプロパティをWebページで使っていいなんて言った覚えはないんですけどね(むしろ使うなと言ってる)。
    http://www.mozilla.gr.jp/standards/webtips0001.html
    -moz-border-radiusはIEBlogのページで指摘されているように品質に重大な問題があって、プレフィックスを外せるような状態ではありません。これは現時点での制限を理解している開発者が使い、実装の変更に確実に追随すると期待できるchrome(Google ChromeのことじゃなくてFirefoxのUI)で角丸を使うためのプロパティです。

    ちなみにIE9でも警告文が出るようです。blogspot.comの管理者(Google?)が互換表示の一覧に掲載されたまま放置してるほど怠惰なせいなので、何かする必要があるとは思いませんけど。

    ReplyDelete
  4. >-moz-プレフィックスの付いたプロパティをWebページで使っていいなんて言った覚えはないんですけどね(むしろ使うなと言ってる)。
    それならば、そもそも使えないようにすべきです。
    使うなといっても、実際使えるのならば、たとえ機能が不完全であっても、人間は使います。
    それも、単に勉強のためではなく、実際の製品のコードで使います。

    一度書かれたコードは、二度と変更されることはありません。

    もし、本当に互換性の問題を考えているならば、そもそも、使える状態で提供するべきではないのです。

    ReplyDelete
  5. 最初に実装して仕様を公開したもの勝ちなら、IE6が非難される理由は何もありませんが? Web開発者がIE6用に一度書かれたコードを書きなおさないのは明らかなのに、どうしてIE6の仕様を丸飲みしないで車輪の再発明に無駄な時間を費やしてるんですか?

    ReplyDelete
  6. IE6は、先のブラウザ戦争の覇者であった。
    IE6は、当時の強豪、Netscapeを、打ち破ったのである。
    当時は、ブラウザといえば、ほぼIEかNetscapeの二者択一であり、
    Netscapeの敗退は、即座に、IEのシェア率を90%以上にまで、押し上げた。
    しかし、IE6は、長くその座に留まりすぎた。

    ブラウザ戦争による、機能の乱立という反省から、標準規格というものができて、多くのブラウザが追随する中で、独りIEは、IE6のままであった。
    多くのブラウザが、パフォーマンスや、W3C規格の定義するDOM level 2, Dom Level 3をサポートしていく中で、IE6は、何もしなかった。というより、何もできなかったのである。

    マイクロソフトは、互換性を第一に考える企業である。皮肉なことに、IEをわずかにでも、規格準拠に改良すれば、既存の多数のWebサイトを、壊すところとなったのである。マイクロソフトは、互換性を第一に考える企業である。

    こうして、他のブラウザなら、あたり前にできる新機能が、IEには、ほとんど実装されずに、今日のIE8までやってきた。

    ReplyDelete
  7. Peter-Paul Kochが言っているのも、Web標準というものがありながら、結局、記述法がバラバラになるなら、意味がないではないかということなのです。

    ReplyDelete
  8. もじら「お前ら-moz使うなよ、絶対に使うなよ!」

    ReplyDelete

You can use some HTML elements, such as <b>, <i>, <a>, also, some characters need to be entity referenced such as <, > and & Your comment may need to be confirmed by blog author. Your comment will be published under GFDL 1.3 or later license with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.