CSSセレクタのマッチングと右から左の評価

問いの立て方：マッチングは「要素起点」で行われる

CSSのセレクタを読むとき人間は左から「.menu の中の .item の a」と読みます。しかしブラウザのスタイル計算（style recalc）は逆向きに動きます。スタイル計算の仕事は、ルールごとに「どの要素に当たるか」を探すのではなく、要素ごとに「この要素に当たるルールはどれか」を確定することです。DOMの各要素について該当ルールを集め、勝者を カスケード で選び、計算値を決めます。この「要素起点」という視点が、右から左の評価を理解する鍵です。

ある要素 a に対して .menu .item a が当たるかを判定する素直な方法を考えます。左から読むなら、まず文書中の全 .menu を探し、その子孫の .item を探し、さらにその子孫の a を探して、対象要素に行き着くかを確かめることになります。これは要素1個の判定なのに、文書を広く走査してしまいます。要素の数だけこれを繰り返せば計算量は爆発します。

右から左に評価する理由：最右端で大半を捨てる

そこでブラウザは、セレクタを最右端の複合セレクタ（rightmost compound selector、キーセレクタ）から左へ評価します。.menu .item a なら、まず対象要素自身が a かを見ます。違えばその場で不一致が確定し、.menu や .item をたどる必要は一切ありません。

.menu .item a   を要素 X について判定する

右端から:
  1. X 自身は a か？        → No なら即不一致（祖先を一切見ない）
  2. X の祖先に .item があるか？ → 結合子 ' '（子孫）を上向きにたどる
  3. その上に .menu があるか？   → さらに上向きにたどる
最初に満たせなくなった時点で不一致を確定

要点は、最右端の判定が最も安く、かつ大多数の要素をここで弾けることです。文書中の大半の要素は a ですらないので、ステップ1で O(1) に近いコストで不一致が決まります。祖先方向の走査（コストの高い部分）は、最右端を通過したごく一部の要素についてだけ発生します。左から評価すると不一致の要素にも全工程を払いますが、右から評価すれば**早期棄却（early rejection）**が効きます。

ブラウザはさらに、最右端のキーをセレクタの種類別（タグ名・クラス・ID）にバケット化した索引を持ちます。要素にルールを照合するとき、その要素のタグ名・各クラス・IDに一致し得るルールだけを索引から引き、無関係なルールは最初から候補にしません。「右から評価」と「キーによる事前バケット化」が組み合わさることで、要素あたりの照合がルール総数に比例しなくなります。

セレクタの「速さ」の実像

この仕組みから、セレクタのコストは左側の長さよりも、最右端のキーがどれだけ選択的（selective）かで大きく決まることが分かります。#id や限定的なクラスがキーなら候補は少なく、汎用的なタグや * がキーだと候補が増え、祖先走査の回数も増えます。

ただし現実のページでは、こうしたセレクタ単体のコスト差が体感差になることは多くありません。スタイル計算の総コストを支配するのは多くの場合何回・何要素ぶん再計算が走るかであり、個々のセレクタの微妙な速さではありません。最適化の主戦場はセレクタの書き換えより、後述する無効化の局所化です。

:has() のコスト：影響が「上流」へ波及する

:has() は関係セレクタ（relational pseudo-class）で、a:has(> img) のように子孫・兄弟側の条件で左の要素を選ぶものです。ここで評価の向きが反転します。通常のセレクタは右端の要素が変わったとき影響を右端に閉じ込められますが、:has() では子孫や後続兄弟の変化が、上流の（左の）要素のマッチ状態を変え得るのです。

li:has(.active) { ... }

.active が li の子孫で付け外しされると、
影響を受けるのは .active 自身ではなく「祖先の li」。
つまり変更点から上流・側方へ無効化が広がる。

素朴に実装すると、.active の付け外しのたびに「この変化で :has() のマッチが変わる祖先はどこまでか」を調べ直す必要があり、最悪では祖先方向や兄弟方向に走査が広がってコストが高くなります。ブラウザはこれを実用化するために、:has() を含むルールを変化の種類ごとに索引化し、:has() の引数に現れる特徴（クラス・タグ・状態）が変わったときだけ、対応する祖先側のスコープに無効化を限定します。

無効化（invalidation）の局所化：ツリー全体を再マッチしない

DOMやスタイルが変わるたびに全要素を全ルールで再マッチしていたら、わずかな class 変更でもページ全体のスタイル計算が走ってしまいます。これを避ける仕組みがスタイル無効化（style invalidation）です。中心となるデータ構造が無効化集合（invalidation set）で、「ある特徴（クラス名・属性・擬似クラス状態）が変化したとき、影響を受け得るルール／要素はどれか」を事前に索引化しておきます。

ルール解析時に索引を構築:
  .open    → { .open を含むルール群 }
  [disabled] → { 属性 disabled を見るルール群 }
  :hover   → { hover に依存するルール群 }

要素 X の class に open が付いた:
  1. invalidation set から .open に紐づくルールを引く
  2. 影響範囲（X 自身か、子孫か、兄弟か）を結合子から決める
  3. その範囲の要素だけスタイルを再計算

ポイントは、変化した特徴をキーに影響範囲だけを引き当てることです。class に open が1つ付いただけなら、.open を参照するルールに関係する要素しか再計算されません。文書の他の部分は一切触りません。これが再計算の局所化で、インタラクションのたびに全ツリーを舐めないための核心です。

無効化には**子孫無効化（descendant invalidation）**もあります。.list .item のようなルールでは、.list が付いた要素の子孫の .item が影響を受けるため、起点要素の子孫方向へ無効化を広げます。ブラウザは結合子から「自分だけで済むか／子孫まで波及するか／兄弟まで波及するか」を判定し、必要最小限のスコープにとどめます。

スタイル計算はパイプラインのどこにあるか

ここまでの照合と無効化は、ブラウザのレンダリングにおけるスタイル（recalc styles）段で起こります。各要素の計算値が確定すると、その結果は次段のレイアウトへ渡され、サイズや位置が解決されます。スタイル計算で再計算スコープを小さく保てても、確定した値がレイアウトに影響するプロパティを含めば、下流でリフローが走ります。

まとめ