もずはっく日記(2009年5月)

Bug-org 476062 box-shadow applied to form controls should drop the native look
初回投稿日時: 2009年05月04日07時17分13秒
最終更新日時: 2009年05月04日07時23分37秒
カテゴリ: CSS Mozilla Core バグ修正
SNS: Tweet (list)

少し前にtrunkと1.9.1branch双方で修正されたバグですが、CSSネタとしておもしろいので紹介しておきます。

ネイティブテーマを利用しているフォームコントロールにbox-shadowを適用した場合にも常に四角の影が適用されるのはよろしくない、というバグです。

結果としてWebKitと同様にネイティブテーマ時にはbox-shadowを無視するという挙動に修正されています。テストケースを参照してもらうと分かるように、ファイルコントロールと画像は対象外です。前者はネイティブコントロールの組み合わせ、後者はネイティブコントロールですら無い、ということです。

このバグの興味深い点はCSSの暫定仕様には何も違反していなかった点です。現在の(publicな)最新仕様では、

The ‘box-shadow’ property attaches one or more drop-shadows to the box.

とあるので、本来、その要素が作り出したボックスの影であるべきです。追加で以下のような追記もあります。

If the box has a nonzero ‘border-radius’, the shadow is rounded in the same way.

ボックスの角がborder-radiusで丸められている場合は影もそれと同様に丸めるべきだとあります。完全にボックス自体の影であると仕様書のエディタ達は考えていると思われます。

ここで、フォームコントロールというものは何なのかを考えてみましょう。

CSS3ではappearanceというプロパティが追加されることでコントロール可能になりますが、CSS2.1では置換要素として考えるしか説明がつきません。つまり、仕様的にはボタン等は前景であって、background-*やborder-*はボタン等の背景のボックスに適用されるべきであると私は考えています。ですが、実際の実装ではこれらのプロパティが指定されると前景であるべきフォームコントロール自体の見た目を変更します。CSS3の仕様書(ドラフト)でもそうするべきである旨が明記されています。もちろんこちらの実際の挙動の方がデザイナにも喜ばれる動作であり、好ましいと思いますが、CSS2.1では説明できない特殊な存在になってしまっています。

つまり、今までの発想ではbox-shadowはCSSがレイアウトのために作り出したボックスに対してかかるべきであって、前景のフォームコントロールの形を意識した影であってはいけないと、仕様書を素直に解釈した場合に考えられると思います(CSS2.1+CSS3 box-shadowというレベルでの話)。実際に、このパターンを考慮していなかったGeckoはそのようにレンダリングしていた訳です。

ですが、やはりネイティブコントロールに四角の影が付くのは直感的にすごい違和感があります。WebKitでは影をネイティブコントロールには適用しない、という乱暴な手法が利用されていました。Geckoもこれに合わせています。乱暴ですが、単純だから、というのが一番の理由です。

理想的にはネイティブコントロールの形の影を描画するようになるべきでしょう。しかし、そのためには複雑な処理が必要となりますが、それに見合うだけの価値があるのかどうかはよく分かりません。また、そもそもネイティブなコントロールに影があること自体がネイティブな見た目ではなくしてしまっていると言えるかもしれません。