CSS上級学習セレクター

私がcssを書き始めた頃、コードの自由度の高さにいつも戸惑ったものです。つまり、同じデザインでも、違う人が実装すれば、違うコードにならざるを得ないのです。しかし、問題があって、同じデザインを違う人が違う手法やコードスタイルで実装した場合、誰がより良い仕事をしたのか評価することが難しくなります。考えてみれば、同じデザインを実装して目的を達成したのだから、プログラムロジックを持たないcssのようなコードに、誰がより良い仕事をしたかを示すものがあるのだろうか。

そして最近では、cssのような記述言語にもコードの品質判定が残っているという考え方に賛同しています。その基準は、MaintainabilityとPerformance、そしてもっと一般的に言えば、開発者に優しく、ブラウザに優しい良いcssです。この記事では、cssのセレクタの観点から、cssコードの品質を向上させる方法を説明します。

キーセレクタとブラウザのスタイルルールのマッチングの原則

cssセレクタの概念は、前回の cssの優先順位付けの新参者 は、各スタイル ルールのうち、どの要素にスタイルを適用するかを記述した部分、つまり {} より前の部分です。今回は、さらにキーセレクタという概念を導入しています。キー セレクタとは、以下のように、各スタイル ルールの冒頭の { の前にある最後のセレクタのことです。

cssセレクタは、その後の属性定義がどの要素に適用されるかを決定するため、cssセレクタを元にブラウザが対応する要素にスタイルを適用するマッチング処理がある。ブラウザのスタイルマッチング方式について、David Hyatt氏は、Writing Efficient CSS for use in the Mozilla UIで、次のように言及しています。

スタイル システムは、一番右のセレクタから始めて、ルールのセレクタを左に移動することでルールにマッチさせます。リトル サブツリーがチェックアウトされ続ける限り、スタイル システムは、ルールに一致するか、不一致のために中止されるまで、左方向に移動し続けます。

とは、ブラウザエンジンが 右から左へ の順で表示されます。特定のスタイル ルールをマッチングする場合、この右から左への処理は、一連のセレクタがすべて読み込まれてマッチングが完了するか、どこかでミスマッチが発生してキャンセルされるまで続けられます（その後、別のスタイル ルールに進みます）。

ブラウザがなぜこの順序でマッチングを行うかについては Stack Overflow の関連ディスカッション . 一般論として説明すると、一番右のキー セレクターはスタイル定義が作用すべき要素を直接表すため、右から左の順序の方が、ブラウザが最初の一致時にスタイル定義を持つ要素のセットを識別し、要素のスタイルを探すときに実際には作用しないほとんどのセレクターをより迅速に回避するために適しています。

より優れた css セレクタとは、スタイル マッチング処理中のマッチ クエリの数を減らし、スタイル マッチングをより速く完了させることによって、ブラウザがフロントエンドのパフォーマンスを最適化できるようなセレクタのことです。これは、ブラウザのスタイルの右から左へのマッチング順序も考慮に入れなければなりません。

cssセレクタの正しい使い方はもっと具体的に

より具体的なキーセレクタ

キー セレクタは、ブラウザ エンジンが読み取るスタイル一致の最初の部分です。したがって、スタイル ルールでより具体的なセレクタを使用すると、ブラウザが一致を検索する回数を減らすのに役立ちます。

例えば、以下のようなセレクタです。

.content .note span{}

最後の1枚 span がキーセレクタであるのに対し span というタグがあり、Webページで非常によく使われています。ブラウザは、まず span はセレクタの読み込みを開始し、その結果、スタイル・マッチングに余分な作業が発生することがあります。

の特定の位置のセレクタにスタイルを設定したいだけだと確信がある場合、そのセレクタを使用することができます。 span 要素にスタイルを定義する方が、より良い方法です。 span クラスの名前を span.note_text というように単純に書き、それを

.note_text{}

クラスセレクタを使用する

クラスセレクタ（class selector）は、最もパフォーマンスが最適化されたセレクタです。クラスに対するIDの欠点は、1つの要素にしか定義ができず、再利用ができないことです。さらに、使い勝手の面でもclassより優れているとは言えません。ある要素がユニークかどうかを判断するのが難しい場合が非常に多いのです。また、IDをjavascript用に確保する一方で、スタイルを定義するためにclassを使用することは、常にベターな方法です。できれば、スタイルの定義にIDを使わないでください。

また、タグはクラスよりもhtmlで繰り返し使用されるため、スタイルのマッチング時にブラウザに余分な作業をさせる可能性があります。もし可能なら、CSSのスタイルクリア（リセット）を除いて、タグセレクタ（エレメントセレクタとも呼ばれる）を使わないでください。

セレクタ列の短縮化

継承の書き方（この場合、正確にはcssのリレーショナルセレクタにおけるインクルードセレクタ）は、cssでは非常に一般的な書き方である。本来の継承の書き方は、同じタグや同じクラス名の要素が2つある場合、親要素のセレクタを追加してセレクタ列を形成することで、2つの要素のスタイルが不要なときに互いに影響し合うことを防ぐというものです。例えば .confirm_layer .submit_btn という名前のクラスは submit_btn という名前のクラスを持ち confirm_layer という名前の親要素を持つ要素にのみ適用されるスタイルです。

しかし、要素のスタイリングの相互作用を避けるといっても、継承されたセレクタを自由に使えるわけではありません。先に述べたように、ブラウザはセレクタ列全体を右から左へ、読み込んで一致させるか、不一致でキャンセルするまで読みます。そのため セレクタ列は短い方がブラウザのマッチング処理を早く完了させることができる . 一方、長いセレクタ列は、次のように非効率とみなされます。

.header ul li .nav_link{}

のように書くことが推奨されています。

.header .nav_link{}

一般に、実際の開発現場では3段階以下の継承で十分とされています。したがって、不要な継承レベルを減らし、より短いセレクタ列を使用する必要があります。

また、セレクタ列が長くなると問題があります。セレクタが長いスタイルルールは、css優先度の計算値も大きくなるため、後から上書きするために新しいスタイルを書く必要がある場合、css優先度を高くするためにセレクタを長く書く（またはIDを使う）必要があります。これはパフォーマンスとコードの可読性にとって悪いことです。

セレクタの連結を避ける

セレクタの連鎖とは、1つの要素に対して複数のセレクタ判定を同時に記述することです。例えば p.name はクラス名 name で、そのタグは p が要素に適用されます。これらの判定の組み合わせは、IDセレクタ、タグセレクタ、クラスセレクタの任意の組み合わせが可能です。

しかし、連鎖したセレクタは過剰な修飾となり、再利用やパフォーマンスの最適化には不利になります。例えば

a#author{}

という書き方を提案。

#author{}

以下は a は不要です。IDは1つの要素にしか対応せず、その要素のタグが何であるかを強調する必要はありません（同じ意味で、クラスも必要ありません）。また、そこには

.content span.arrow{}

のように書くことが推奨されています。

.content .arrow{}

以下は span.arrow の中に span も不要です。一方では、スタイルをマッチングする際にブラウザに余分な仕事をさせることになります。 arrow 要素のタグ名は span となり、パフォーマンスが低下します。一方、この修飾を外すと .arrow のスタイル定義は、より多くの要素で使用することができ、再利用性も高くなります。そうでない場合は、このスタイル定義を span タグを使用します。

同様に、複数のクラスが連鎖的に記述されるのは、次のような場合です。

.tips.succuss{}

というようにネーミングを変えて書くことをお勧めします。

.tips_succuss{}

これにより、ブラウザは余計なスタイルマッチング作業を減らすことができます。

また、IE6 では、複数のクラスセレクタを連結して記述した、例えば .class1.class2.class3 通常であれば、これらすべてのクラスを同時に持つ要素にのみ、スタイルが適用されます。しかし、IE6では最後の1つしか認識されず、その1つは .class3 このセレクタは、スタイルが適用される唯一の要素です。

例外事項

セレクタの書き方に関する上記の提案は、ブラウザのレンダリングパフォーマンスの最適化とコードの再利用性の分析から得られた理論的な結果に過ぎません。実際には、この提案に忠実に従う必要はありません。たとえば、実際に intro 要素内のすべての a タグの要素が特定のスタイルでスタイリングされている場合は .intro a のようなセレクタを使用するのが賢明である。

結論

効率的なCSSセレクタの使い方については、google developer's の 効率的なCSSセレクタを使用する .

現在では、モダンブラウザもスタイルマッチングに最適化されてきています( CSSセレクタの性能が変わった! ) 、もはや心配する必要のない側面もあります。しかし、だからといって、賢明なcssセレクタの記述について考える必要がないわけではありません。cssセレクタのパフォーマンスの最適化は依然として行われており、セレクタは思い通りに使われるのではなく、あなたの意図をよりよく反映するものであるべきなのです。さらに言えば、そんなちょっと微妙に考え抜かれたcssセレクタを書くことは、決して難しいことではありません。そうしたいと思い、そういう習慣を形成していけば、自然と上手くなっていくものですから、いかがでしょうか。

以上、この記事が皆様の学習の一助となり、スクリプトハウスをより一層応援していただければ幸いです。