CSSの進化は、時として私たちフロントエンドエンジニアの「JavaScriptへの過剰な依存」を優しく、しかし容赦なく剥ぎ取ってくれる。その最たる例が `:required` 疑似クラスだ。
単なる「必須項目の入力欄に赤いアスタリスクを付けるためのセレクタ」だと思っていないか？ もしそうなら、君はブラウザのレンダリングエンジンが裏側でどれほど効率的に動いているか、その恩恵の半分も見逃していることになる。
今回は、JavaScriptによるステート管理の呪縛から逃れ、ブラウザのネイティブ機能を極限まで引き出して堅牢なWebアプリケーションを構築するための `:required` の深淵なる世界へ案内しよう。
—
1. なぜ `:required` なのか？ DOMツリーとメモリ効率の真実
モダンなSPAフレームワークを使っていると、フォームのバリデーション状態や「必須かどうか」のフラグをすべてJSのリアクティブなステート（Vueの `ref` や Reactの `useState` など）で管理したがる傾向がある。気持ちは分かる。すべてをJavaScriptの支配下に置いたほうが、心理的安全性が高いからだ。
しかし、アーキテクチャの観点から見れば、これは悪手になり得ることの方が多い。
JSで動的にクラス（例えば `.is-required` など）を付与する場合、次のようなコストが発生する。
1. メモリ消費: すべての入力要素の状態をVNodeやJSのメモリ空間に保持し続ける必要がある。
2. メインスレッドの占有: 状態変化のたびにReact等の仮想DOM差分アルゴリズムが走り、最終的にDOMを書き換える。
3. 再レンダリングの連鎖: 1つの入力値が変わるだけで、フォーム全体が再評価される無駄。
一方、HTMLの `required` 属性と CSSの `:required` 疑似クラスの組み合わせは、ブラウザのC++層（Blink, Gecko, WebKit）で直接処理される。DOMノードが生成された瞬間、あるいは属性が付与された瞬間に、ブラウザのスタイルエンジンは内部のフラグメントを元に一瞬でセレクタマッチングを行う。JSのメインスレッドを1バイトたりとも汚染せず、メモリもほぼ消費しない。
これが、真にスケーラブルなWebアプリケーションがネイティブの属性と疑似クラスを愛する理由だ。
—
2. 実務で直面する「非同期の競合」とCSSの優位性
大規模なエンタープライズ向けフォームを構築していると、APIから動的にスキーマ（JSON Schemaなど）を取得し、それに従ってフォームを動的生成するケースによく遭遇する。
「必須項目が動的に変わるのだから、CSSだけでスタイリングするのは無理だ」と早合点してはいけない。ここでもJSで無理やりクラスを付け外しするのではなく、データ駆動で `required` 属性そのものをDOMに反映させるべきなのだ。
属性がDOMに存在しさえすれば、CSS側は静かに、しかし確実にそれに追従する。
ここで重要なのは、`novalidate` 属性をフォームにつけておくことだ。ブラウザデフォルトの醜いポップアップバリデーションを無効化しつつ、`:required` によるスタイリングの恩恵だけを完全にコントロール下置く。これがプロの選択だ。
—
3. レンダリング負荷を最小限にするスタイリング設計
さて、`:required` を使う上で、CSSのパフォーマンスに関する非常に重要な知見を共有しよう。
CSSセレクタの評価は、右から左（Key Selectorから祖先方向）に向かって行われる。つまり、無駄に複雑なセレクタを書くと、ブラウザのペイント＆レイアウトフェーズに無用な負荷をかけることになる。
特に `:required` は、ユーザーの入力（`input` イベントや `change` イベント）のたびに、疑似クラスの状態変化（厳密にはフォーマットやバリデーション状態の変更）をトリガーに再計算される可能性があるため、セレクタは極力フラットに保つべきだ。
以下の実用的なCSSコードを見てほしい。
/ =================================================================
高パフォーマンス・フォームアーキテクチャ
================================================================= /
/ 1. ベースの入力コントロール /
.control-input {
display: block;
width: 100%;
padding: 0.75rem 1rem;
font-size: 1rem;
border: 1px solid var(–color-border-base, #ccc);
border-radius: 4px;
transition: border-color 0.2s ease, box-shadow 0.2s ease;
background-color: #fff;
}
/ 2. フォーカス時の振る舞い /
.control-input:focus {
outline: none;
border-color: var(–color-primary, #0066cc);
box-shadow: 0 0 0 3px rgba(0, 102, 204, 0.15);
}
/
3. :required 疑似クラスを活用したスタイリング
DOMの属性ベースで判定するため、JSのステートに依存しない
/
.control-input:required {
/ 必須フィールドであることを示す控えめなインジケーター（例: 左側のボーダーをアクセントカラーに） /
border-left-width: 4px;
border-left-color: var(–color-required, #e63946);
}
/
4. 【重要】「まだ何も入力されていない初期状態」での赤色エラー表現を避ける
ユーザーがページを開いた瞬間に、必須項目が赤く染まっているUIは最悪のUXだ。
これを防ぐため、未入力かつ未タッチ（またはプレーンな状態）の制御が必要になるが、
ここで :placeholder-shown や :user-invalid を組み合わせるのがモダンCSSの真髄。
/
/
プレーンな状態で、かつ required な要素のラベルを装飾する例
隣接セレクタや子孫セレクタの最適化
/
.field-group:has(.control-input:required) .field-label::after {
content: ” “;
color: var(–color-required, #e63946);
font-weight: bold;
}
ここで紹介した `:has()` 疑似クラスとの組み合わせに注目してほしい。親要素側（`.field-group`）に「必須の子要素が含まれているか」を判定させ、ラベル側にアスタリスクを付与する。これにより、HTMLの構造を汚さず、CSSだけで意味論的な装飾を完結させることができる。
—
4. 重大なバグの回避策：UXを破壊する「初期赤色表示」の罠
`:required` を使い始めたエンジニアが必ずハマる罠がある。それは、「ページを表示した瞬間から、すべての必須入力欄がエラーのような赤枠で囲まれてしまう」という問題だ。
`:required` は「required属性があるか」だけでマッチする。ユーザーがまだそのフィールドに触れてもいない、ページを開いたコンマ数秒の段階でもマッチしてしまうのだ。これではユーザーは「まだ何も入力していないのに怒られている」と感じ、Cognitive Load（認知負荷）が一気に跳ね上がる。
この問題を回避するために、かつてはJSで `.touched` や `.dirty` といったクラスを地道につけていたはずだ。だが、もうその必要はない。
現代のブラウザには、`:user-invalid` や `:placeholder-shown` という強力な味方がいる。
/
NGパターン：これだとページロード直後に全必須項目が赤くなる
.control-input:required:invalid { border-color: red; }
/
/
OKパターン：
:user-invalid は、ユーザーがその要素に入力を行い、かつバリデーションエラーになった時だけ発火する。
（ブラウザのネイティブな対話状態をCSSからフックする神機能）
/
.control-input:required:user-invalid {
border-color: #e63946;
background-color: rgba(230, 57, 70, 0.02);
}
/
さらにプレースホルダーが表示されている間（＝未入力状態）はエラーカラーを抑制するテクニック
/
.control-input:required:placeholder-shown {
border-color: var(–color-border-base, #ccc);
border-left-color: var(–color-required, #e63946); / 必須のマークだけは残す /
}
この `:user-invalid` と `:required` を組み合わせることで、JavaScriptを1行も書くことなく、「ユーザーが意図的に不正なデータを入力し、フォーカスを外した瞬間（あるいは送信を試みた瞬間）」にのみ、完璧なタイミングでエラーースタイルを適用できる。
—
5. チーフアーキテクトからの提言
フロントエンドのコードベースが肥大化する原因の多くは、「本来ブラウザがネイティブで持っている機能」を、JSのフレームワークでわざわざ再発明しようとする構造的欠陥にある。
フォームの必須判定やそのスタイリングは、まさにその代表例だ。
JSのステートに頼り切りになり、すべての入力イベントを監視してクラスをトグルするようなコードは、今すぐ捨て去るべきだ。HTMLに `required` を書き、CSSで `:required` と `:user-invalid` を巧みに操る。これだけで、コード量劇的に削減され、メモリ効率は跳ね上がり、レンダリングパイプラインは滑らかになる。
ブラウザを信じろ。エンジンは、私たちが想像する何倍も賢く、最適化されているのだから。
コメント