ブラウザーがCSSセレクターを右から左に一致させるのはなぜですか？

CSSセレクターは、ブラウザーエンジンによって右から左にマッチングされます。したがって、まず子供を見つけ、次に親をチェックして、ルールの残りの部分と一致するかどうかを確認します。

1. どうしてこれなの？
2. それは仕様が言っているからというだけですか？
3. 左から右に評価した場合、最終的なレイアウトに影響しますか？

私にとって最も簡単な方法は、要素数が最も少ないセレクターを使用することです。したがって、最初にIDを使用します（1つの要素のみを返す必要があるため）。次に、おそらくノードまたはノードの数が最も少ないクラスまたは要素です。たとえば、ページにスパンが1つしかない場合があるため、スパンを参照するルールを使用してそのノードに直接移動します。

ここに私の主張を裏付けるいくつかのリンクがあります

1. http://code.google.com/speed/page-speed/docs/rendering.html
2. https://developer.mozilla.org/en/Writing_Efficient_CSS

親でなければならない子のすべての親ではなく、親の子（多くの場合）をすべて見る必要がないように、このように行われているようです。DOMが深い場合でも、RTLマッチングでは複数のノードではなく、レベルごとに1つのノードのみを参照します。CSSセレクターLTRまたはRTLを評価する方が簡単/高速ですか？

ブラウザーがセレクターマッチングを実行している場合、ブラウザーには1つの要素（スタイルを決定しようとしている要素）とすべてのルールとそのセレクターがあり、どのルールが要素に一致するかを見つける必要があることに注意してください。これは、通常のjQueryとは異なります。たとえば、セレクターが1つしかなく、そのセレクターに一致するすべての要素を見つける必要がある場合です。

セレクターが1つだけで、そのセレクターと比較する要素が1つしかない場合は、左から右の方が意味がある場合があります。しかし、それは明らかにブラウザの状況ではありません。ブラウザはGmailなどをレンダリングしようとしていて、<span>スタイルを設定しようとしているものを持っています。Gmailがスタイルシートに設定している10,000以上のルール（私はその数値を上げていません）。

特に、ブラウザは、問題の要素と一致しないと見なしているほとんどのセレクタを調べています。したがって、問題は、セレクターができるだけ速く一致しないことを決定することの1つになります。それが一致する場合に少し余分な作業が必要な場合でも、一致しない場合に保存したすべての作業のために、引き続き勝利します。

セレクターの右端の部分を要素と照合することから始める場合は、一致しない可能性があり、完了します。それが一致する場合、より多くの作業を行う必要がありますが、ツリーの深さに比例するだけで、ほとんどの場合それほど大きくありません。

一方、セレクターの左端の部分を一致させることから始める場合、何と一致しますか？DOMを調べ、それに一致する可能性のあるノードを探す必要があります。左端の部分に一致するものが何もないことに気づくだけで、しばらく時間がかかる場合があります。

したがって、ブラウザーは右から一致します。これは明らかな出発点を提供し、ほとんどの候補セレクターを非常に迅速に取り除くことができます。一部のデータはhttp://groups.google.com/group/mozilla.dev.tech.layout/browse_thread/thread/b185e455a0b3562a/7db34de545c17665（表記はわかりにくいですが）で確認できますが、特にGmailの場合の結果がわかります2年前、（ルール、エレメント）ペアの70％で、ルールの右端のセレクターのタグ/クラス/ IDの部分を調べただけでは、ルールが一致しないと判断できました。Mozillaのページロードパフォーマンステストスイートに対応する数は72％でした。そのため、すべてのルールの2/3をできるだけ早く取り除き、残りの1/3とのみ一致させることを心配する価値があります。

また、確実に一致しないルールに一致させようとすることを回避するために、ブラウザーがすでに行っている他の最適化があることにも注意してください。たとえば、右端のセレクターにIDがあり、そのIDが要素のIDと一致しない場合、Geckoではそのセレクターをその要素とまったく一致させる試みは行われません。試行される「ID付きセレクター」のセット要素のIDのハッシュテーブル検索から取得されます。したがって、これはルールの70％であり、右端のセレクターのタグ/クラス/ IDだけを考慮しても、一致しない可能性がかなりあります。

右から左への解析は、ボトムアップ解析とも呼ばれ、ブラウザにとって実際には効率的です。

以下を検討してください。

#menu ul li a { color: #00f; }

ブラウザのために最初にチェックしa、その後、li、そしてul、その後#menu。

これは、ブラウザがページをスキャンしているときに、現在の要素/ノードと、それがスキャンした以前のすべてのノード/要素を調べる必要があるためです。

注目すべきことは、ブラウザーが完全なタグ/ノードを取得した瞬間にブラウザーが処理を開始し、スクリプトが見つかった場合を除いてページ全体を待つ必要がないことです。この場合、一時停止してスクリプトの実行が完了してから、進む。

逆の場合は、ブラウザが最初のチェックでスキャンしている要素を見つけたため、効率が悪くなりますが、その後、すべての追加のセレクターについてドキュメントを調べ続ける必要がありました。このため、ブラウザーはHTML全体を持っている必要があり、CSSペイントを開始する前にページ全体をスキャンする必要がある場合があります。

これは、ほとんどのlibがdomを解析する方法とは逆です。そこでdomが構築され、ページ全体をスキャンする必要はありません。最初の要素を見つけて、その中の他の要素を照合するだけです。

より具体的なものからそれほど具体的でないものへとカスケードすることができます。また、アプリケーションでの短絡も可能です。より具体的なルールが親ルールが適用されるすべての側面に適用される場合、すべての親ルールは無視されます。親に他のビットがある場合、それらが適用されます。

逆の場合は、親に従ってフォーマットし、子に何か異なるものがあるたびに上書きします。長い目で見れば、これはすでに処理されているルールの項目を無視するよりもはるかに多くの作業です。