`:enabled` 疑似クラスの深層：フォームアーキテクチャの静的最適化とブラウザエンジンの内部挙動
こんにちは。フロントエンドの裏側、特にブラウザがDOMをどう解釈し、どうピクセルに変換しているのかという泥臭い領域に異常なまでの情熱を注いでいるチーフアーキテクトだ。
今回は、CSSのセレクタ群の中でも地味な存在として扱われがちな `:enabled` 疑似クラスについて話をしよう。
「お、フォームの有効状態を取るやつね、知ってるよ。`` に色つけるやつでしょ」と思ったそこの君。もしモダンな大規模Webアプリケーションのパフォーマンスやメモリ効率、そして非同期処理が絡む複雑な状態管理の文脈において、単に「デフォルトの装飾用」としてしかこれを見ていないなら、今すぐその認識をアップデートしてもらう必要がある。
CSSのセレクタは、単なる「見た目の指定」ではない。それはブラウザのレンダリングエンジンに対する強力なクエリ指示書であり、DOMツリーの走査コストやメモリのガベージコレクション、さらにはJavaScriptのメインスレッドのブロッキング回避にまで直結する重要なアーキテクチャ要素なのだ。
今日は、プロのエンジニアが知るべき `:enabled` の真価と、現場で踏みがちな地雷の回避策について、ブラウザの内部挙動の視点から徹底的に解き明かしていこう。
—
1. ブラウザエンジンの内部挙動：なぜ `:not([disabled])` ではなく `:enabled` なのか？
まずは、私たちの誰もがやりがちな「アンチパターン」の話から始めよう。
フォーム要素が有効なときだけにスタイルを当てたい。そんなとき、素朴な実装として以下のようなCSSを書いたことはないだろうか。
/ アンチパターンの例：属性セレクタによる代用 /
input:not([disabled]) {
border-color: var(–color-border-active);
}
一見、動いているように見える。しかし、ブラウザのレンダリングエンジンの内部（BlinkやGecko、WebKit）において、この2つ（`:enabled` と `:not([disabled])`）は全く異なるコストで処理されている。
DOMのステートフラグ vs 属性の有無の判定
HTMLのフォーム要素（``, `