フォームの要塞化：`:valid` 疑似クラスがもたらすリアクティブ・アーキテクチャの極限
ブラウザのレンダリングエンジンとDOMのライフサイクルを愛してやまないエンジニア諸君。日々のフロントエンド開発、ご苦労様だ。
ReactやVueといった現代のコンポーネント指向フレームワーク全盛の時代において、フォームのバリデーション状態管理はどう実装されているだろうか？ 大半のプロジェクトでは、状態管理ライブラリの肥大化、あるいは煩雑な `useState` の嵐による再レンダリングの連鎖に頭を悩ませていることだろう。「入力値が変わるたびにステートを更新し、正規表現を走らせ、クラス名を動的に付与する」――そんな非効率なJavaScript駆動のアーキテクチャに、そろそろ辟易している頃ではないだろうか。
今回は、CSSネイティブの隠れた強力な武器、`:valid` 疑似クラスにスポットを当てる。これは単なる「HTML5のバリデーション補助」などという生ぬるいものではない。ブラウザのC++層で最適化されたネイティブのステートマシンを直接ハックし、JSの介在をゼロにしながら、堅牢でメモリ効率の極めて高いUIリアクティビティを実現するためのマスターキーなのだ。
—
1. なぜ JS バリデーションはスケーラビリティの敵なのか
大規模なエンタープライズ向けWebアプリケーションにおいて、フォームの複雑さは爆発的に増加する。数十の入力フィールド、依存関係のあるバリデーション、リアルタイムの非同期チェック。これらをすべてJavaScriptで制御しようとすると、以下の致命的なコストを支払うことになる。
1. メインスレッドの圧迫: 入力のたびに（あるいは `debounce` を挟むにしても）リスナーが発火し、仮想DOMの差分検出やステートの同期が走る。
2. メモリリークの温床: 複雑なイベントリスナーの解除漏れや、クロージャによる不要なメモリ保持。
3. 描画のラグ（Jank）: 入力フィードバックの遅延がユーザー体験を直撃する。
対して、ブラウザのパーサーとレイアウトエンジンは、DOMノードの属性（`required`, `pattern`, `minlength` など）をベースにしたバリデーション状態を、内部のC++メモリ空間で極めて高速に管理している。`:valid` 疑似クラスは、このブラウザのネイティブステートに直接フックする。JavaScriptによる状態監視のループを完全に排除し、レンダリングパイプラインの最も効率的なレイヤーでUIを変化させることができるのだ。
—
2. `:valid` の罠：未入力（Empty）状態という最大の落とし穴
さて、ここからが本題だ。`:valid` を使いこなす上で、多くのジュニア〜ミドルクラスのエンジニアが陥る最初の、そして最大の罠がある。
「`input:required` に何も入力していない初期状態、あれはバリデーションを満たしていないから `:invalid` だよな？」
その通り。では、次の一文を見てほしい。
「じゃあ、何も入力されていない空の input は `:valid` に該当しないよな？」
── 残念、それはブラウザの仕様における大きな誤解だ。
HTML5の仕様上、「値が空（Empty）であり、かつ `required` 属性が指定されていない」 input 要素は、初期状態で `:valid` と判定される。さらに言えば、`required` が指定されている要素であっても、ユーザーが一度もフォーカスし、入力し、インタラクションを完了させる前（初期描画時）から真っ赤なエラー表示（`:invalid` の適用）を出すのは、UXの観点から最悪のアンチパターンだ。ユーザーがページを開いた瞬間にエラーだらけのフォームが表示されたら、それだけで離脱率が跳ね上がる。
ここで登場するのが、CSS3のセレクタモジュールにおける最強の組み合わせ、`:placeholder-shown` との協調だ。
実務で使える堅牢なセレクタの構築
ユーザーがまだ何も入力していない状態（かつプレースホルダーが表示されている状態）を正確に除外し、本当に「入力が完了し、かつ妥当である」瞬間だけを捉えるための実用的なCSSアーキテクチャを見てみよう。
/ ==========================================================================
フォーム要塞化のための CSS アーキテクチャ (Modern CSS Validation)
========================================================================== /
/ ベースの入力フィールド /
.form-input {
display: block;
width: 100%;
padding: 0.75rem 1rem;
font-size: 1rem;
border: 2px solid var(–color-border-default);
border-radius: 4px;
background-color: var(–color-bg-primary);
transition: border-color 0.2s ease, box-shadow 0.2s ease;
}
/ 1. プレースホルダーが表示されている（＝ユーザーがまだ入力を始めていない）間は、
requiredであってもバリデーションスタイルをミュートする /
.form-input:placeholder-shown {
border-color: var(–color-border-default);
}
/ 2. ユーザーが入力を開始し（プレースホルダーが消え）、
かつHTML5のバリデーションルールをクリアした場合のみ :valid が真価を発揮する /
.form-input:not(:placeholder-shown):valid {
border-color: var(–color-success);
background-image: url(“data:image/svg+xml,…”); / 成功アイコン等 /
background-repeat: no-repeat;
background-position: right 1rem center;
}
/ 3. 入力中、かつルール違反をしている場合（ただし初期状態を除く） /
.form-input:not(:placeholder-shown):invalid {
border-color: var(–color-error);
box-shadow: 0 0 0 3px rgba(255, 0, 0, 0.1);
}
このアプローチの美しさは、「JavaScriptのステート管理を一切必要とせず、DOMの属性と疑似クラスの論理演算だけで完璧なインタラクションを実現している点」にある。
—
3. レンダリング最適化とメモリ効率の極限
「CSSだけでここまでできるのはわかったが、実際のブラウザのパフォーマンスへの影響はどうなのだろうか？」と疑問に思うシニアエンジニアもいるだろう。
結論から言えば、`:valid` などの状態疑似クラスを活用したスタイリングは、JavaScriptによるDOM操作やクラスの付け替えと比較して、圧倒的にメモリ効率が良い。
再計算（Recalculate Style）と再レイアウト（Reflow）の最小化
JSでクラス名を変更する場合、フレームワークの仮想DOMの差分アルゴリズムが走り、DOMツリーのプロパティ書き換え、そしてブラウザのスタイル再計算トリガーという重いパイプラインを経由する。
一方、ネイティブの `:valid` 疑似クラスは、ユーザーが文字を入力した瞬間にブラウザのC++層でステートが更新され、該当するCSSルールが直接ヒットする。スタイル・再計算のスコープがその input 要素（および影響を受ける隣接・子孫要素）に局所化されやすく、不要なレイアウトスラッシングを防ぐことができるのだ。
フォーム全体の状態連動：HAS 疑似クラスとの融合
さらに、CSS Selectors Level 4で導入された `:has()` 疑似クラスと `:valid` を組み合わせることで、フォーム全体のバリデーション状態に応じたダイナミックなスタイリングが可能になる。JSで「全ての入力が有効になったら送信ボタンを活性化する」というロジックを書く必要すらなくなるのだ。
/ フォーム内に1つでも無効な入力がある場合の送信ボタンの制御 /
.form-container:has(input:invalid) .submit-button {
background-color: var(–color-disabled);
cursor: not-allowed;
opacity: 0.6;
pointer-events: none; / クリックイベントを物理的に遮断 /
}
/ すべての必須・入力フィールドが :valid を満たした瞬間、ボタンが覚醒する /
.form-container:not(:has(input:invalid)) .submit-button {
background-color: var(–color-primary);
cursor: pointer;
opacity: 1;
pointer-events: auto;
box-shadow: 0 4px 12px rgba(0, 123, 255, 0.3);
}
このコードを見た時、ギークな君なら震えるはずだ。JavaScriptのイベントリスナーやバリデーションライブラリの肥大したバンドルサイズを完全に排除し、ブラウザのネイティブエンジンだけで「フォーム全体のリアクティブな活性制御」が完結している。これが、モダンCSSアーキテクチャの目指す究極の姿である。
—
4. アーキテクトが知るべきエッジケースとハック
もちろん、実務の現場は綺麗事だけでは済まない。`:valid` を採用する上で、いくつかの厄介なエッジケースと、それを突破するための知見を共有しておこう。
エッジケース 1: カスタムコンポーネント（デザインシステム）との統合
ヘッドレスUIや独自のカスタムコンポーネントライブラリを使っている場合、内部のネイティブ `` が隠蔽されていることがある。この場合、親要素やカスタムコンポーネントのホスト要素に対して直接 `:valid` を適用することはできない（CSS Shadow DOMのカプセル化の壁がある）。
対策: カスタムコンポーネントの設計において、内部の `` の状態を `:host` やカスタムプロパティ（CSS Variables）に伝播させるか、あるいは内部で `internals.setValidity()` を活用する Element Internals API を組み合わせる必要がある。Web Componentsのセマンティクスとネイティブバリデーションの融合については、また別の機会に深く語るとしよう。
エッジケース 2: ブラウザ間の微妙な実装差異
Safari、Chrome（Blink）、Firefox（Gecko）の間で、特定の `type` 属性（例えば `type=”number”` や `type=”date”`）における `:valid` / `:invalid` の評価タイミングや、フォーカス外での挙動にわずかな揺らぎが存在する。
特に `number` フィールドで空欄のままフォーム送信を試みた際の挙動などは、ブラウザごとに解釈が分かれることがあるため、必ずクロスブラウザでの実機検証を怠らないこと。とはいえ、基本原則である `:not(:placeholder-shown)` や `:focus` との組み合わせを適切に行うことで、大半の差異は吸収可能だ。
—
結びにかえて：ネイティブへの回帰と未来
我々は長年、JavaScriptという万能ナイフを使ってあらゆるUIの状態管理を行ってきた。その結果として、肥大化したバンドルサイズ、複雑化したステート管理、そしてメインスレッドの疲弊という技術的負債を抱え込んできた。
`:valid` 疑似クラスをはじめとするモダンCSSの機能群は、単なる「見た目を飾る道具」ではない。それは、ブラウザの持つ本来のパフォーマンスとネイティブな能力を最大限に引き出し、JavaScriptを「本当に必要なビジネスロジック」に集中させるための、極めて高度なインフラストラクチャなのだ。
次にフォームを設計する際は、ステートを書く手を一旦止め、CSSのステートマシンに語りかけてみてほしい。ブラウザは、君が想像しているよりもはるかに賢く、そして速い。
コメント