フォームバリデーションの美学：`:valid` と `:invalid` を実務の荒野でどう手懐けるか
フロントエンドのアーキテクチャにおいて、フォームのバリデーション状態に応じたスタイリングは、常に頭痛の種だった。かつては、JavaScriptでイベントを監視し、入力値が変わるたびにDOMを走査してクラスを付け替えるという、泥臭いDOM操作が標準的だった。
しかし、現代のCSSエンジンは、私たちが想像するよりもはるかに賢い。ブラウザのネイティブなHTML5バリデーション機構と連動する `:valid` および `:invalid` 擬似クラスを適切に活用すれば、メインスレッドをJavaScriptの処理で汚すことなく、宣言的かつ高速なUIフィードバックを実現できる。
今回は、この2つの擬似クラスを単なる「赤枠・緑枠をつける便利機能」としてではなく、大規模Webアプリケーションに耐えうる堅牢なコンポーネント設計の武器として、その内部挙動やパフォーマンスへの影響、そして実務で必ず直面する「あの罠」の回避策も含めて徹底的に解剖していこう。
—
1. レンダリングエンジンとメモリ効率の裏側
まず前提として、`:valid` や `:invalid` をはじめとするステートフルな擬似クラスは、ブラウザのスタイル計算パイプラインにおいてどのように扱われているかを知る必要がある。
BlinkやGeckoなどのモダンなレンダリングエンジンは、フォーム要素の `ValidityState` インターフェースの変更を検知すると、該当要素のスタイル再計算（Recalculate Style）のトリガーを引く。ここで重要なのは、これらの擬似クラスが「DOMツリー全体を巻き込むリフロー（レイアウト再計算）を最小限に抑え、ペイントまたはコンポジット層の更新だけで完結しやすい」という点だ。JavaScriptによるクラスの動的付与と比較して、ブラウザのC++層で直接ステート判定が行われるため、メモリのヒープ領域を圧迫せず、GC（ガベージコレクション）の頻度も劇的に下げられる。
ただし、ここで最初の「実務の罠」が存在する。
2. 初期表示時の「赤枠爆弾」問題とスマートな回避策
`:invalid` を使い始めた開発者が口を揃えて遭遇するバグがある。それは、ページを開いた瞬間、まだユーザーが一文字も入力していない空の必須入力欄が真っ赤に染まるという現象だ。
ユーザーがフォームに足を踏み入れた瞬間に「お前は間違っている」とエラーを突きつけるUIは、最悪のUXデザインと言わざるを得ない。では、これをどう防ぐべきか？
かつては「JavaScriptで `touched` クラスを付与する」というアプローチが取られていたが、我々はCSSアーキテクチャの力でこれを解決できる。鍵となるのは、ユーザーが一度でもその要素にインタラクションしたか（あるいはフォームが送信試行されたか）の状態を組み合わせることだ。
/ 致命傷：これだと初期表示で全入力欄が赤くなる /
input:invalid {
border-color: #ff3366;
}
/ 上級アプローチ：ユーザーのインタラクション後、またはプレースホルダー非表示時のみ適用 /
/ あるいは :placeholder-shown を逆手に取る /
input:not(:placeholder-shown):invalid {
border-color: #ff3366;
}
input:not(:placeholder-shown):valid {
border-color: #00cc66;
}
`:placeholder-shown` は、「プレースホルダーが表示されている状態」にマッチする。つまり、ユーザーが何かを入力し始めると、この擬似クラスはマッチしなくなる。これを利用して `not(:placeholder-shown)` と組み合わせることで、「何かを入力し始めたけれど、まだバリデーションを満たしていない」という瞬間を正確に捕捉できるのだ。
—
3. 実践：堅牢なコンポーネント設計とCSS設計（BEMの融合）
実際のプロジェクトで使える、アクセシビリティ（a11y）にも配慮したフォームグループのコード例を見てみよう。ここでは、CSSカスタムプロパティ（CSS変数）と組み合わせることで、テーマ変更やデザインシステムの変更にも耐えうる構造にする。
有効なメールアドレスを入力してください。
/ デザイントークンの定義 /
:root {
–color-border: #cbd5e1;
–color-focus: #3b82f6;
–color-valid: #10b981;
–color-invalid: #ef4444;
}
.form-field {
display: flex;
flex-direction: column;
gap: 0.5rem;
margin-bottom: 1.5rem;
font-family: system-ui, -apple-system, sans-serif;
}
.form-field__label {
font-size: 0.875rem;
font-weight: 600;
color: #1e293b;
}
.form-field__input {
padding: 0.75rem 1rem;
font-size: 1rem;
border: 1px solid var(–color-border);
border-radius: 0.375rem;
outline: none;
transition: border-color 0.2s ease, box-shadow 0.2s ease;
}
.form-field__input:focus {
border-color: var(–color-focus);
box-shadow: 0 0 0 3px rgba(59, 130, 246, 0.15);
}
/ エラーメッセージの初期状態：不可視かつ高さを奪わない /
.form-field__error-msg {
font-size: 0.75rem;
color: var(–color-invalid);
opacity: 0;
transform: translateY(-4px);
transition: opacity 0.2s ease, transform 0.2s ease;
pointer-events: none;
}
/
【重要】
初期表示時のエラー表示を防ぐため、`:placeholder-shown` が外れ、
かつ `:invalid` かつ（ユーザーがフォーカスを外した後の判定として `user-invalid` 的な挙動をさせるため）
あるいはフォーム自体が送信試行されたコンテキスト（`.is-submitted`）を組み合わせる。
/
/ パターンA: プレースホルダーが消え、かつ不正な値の場合 /
.form-field__input:not(:placeholder-shown):invalid {
border-color: var(–color-invalid);
}
.form-field__input:not(:placeholder-shown):invalid + .form-field__error-msg {
opacity: 1;
transform: translateY(0);
}
/ パターンB: 正常に入力された場合 /
.form-field__input:not(:placeholder-shown):valid {
border-color: var(–color-valid);
}
このアプローチの美しいところは、JavaScriptを一切書かずに「入力中はリアルタイムにエラー/サクセスの判定を行い、メッセージのフェードイン・アウトまでGPU支援を受けながらスムーズに処理できる」という点だ。
—
4. 非同期バリデーション（サーバーサイド連携）との競合とアーキテクチャの限界
さて、ここまでCSSネイティブの `:valid` / `:invalid` を絶賛してきたが、シニアエンジニアとして限界も知っておく必要がある。
実際のWebアプリケーションでは、「入力されたメールアドレスがすでにデータベースに存在するかどうか（重複チェック）」といった非同期バリデーション（Async Validation）が頻繁に要求される。当然、ブラウザのHTML5バリデーションエンジンは、ローカルの正規表現（`pattern` 属性など）やデータ型しか知らないため、サーバーサイドの非同期な状態を `:valid` に直接結びつけることはできない。
ここでアーキテクチャ上の選択迫られる。
1. JavaScriptでカスタムValidityを操作する
ブラウザのネイティブAPIである `input.setCustomValidity(‘このメールアドレスは既に使われています’)` をJavaScriptから叩くことで、要素を強制的に `:invalid` 状態に落とし込むことができる。
2. CSSのステートクラスを併用するハイブリッド設計
非同期処理が絡む複雑なフォームでは、純粋なCSSセレクタだけに頼るのではなく、JavaScript側で状態管理を行いつつ、CSS側では変数の切り替えやユーティリティクラス（`.is-server-invalid` など）を受け入れる設計にする。
// 例：非同期バリデーションの結果をネイティブAPIに教え込むギークな手法
const emailInput = document.querySelector(‘#user-email’);
emailInput.addEventListener(‘blur’, async (e) => {
const value = e.target.value;
if (!value) return;
const isDuplicate = await checkEmailOnServer(value);
if (isDuplicate) {
// ネイティブのバリデーションステータスをハックする
emailInput.setCustomValidity(‘このメールアドレスは既に登録されています。’);
} else {
emailInput.setCustomValidity(”); // エラークリア
}
// ブラウザに再検証を強制
emailInput.reportValidity();
});
このように、`setCustomValidity()` を用いることで、JavaScriptの非同期結果をブラウザ標準の `:invalid` 擬似クラスの世界に橋渡しすることができる。これにより、CSS側は「どのような理由であれ `:invalid` であれば赤くする」という単一責任の原則を保ち続けることができるのだ。
—
5. チーフアーキテクトからの提言
`:valid` と `:invalid` は、単なる「便利なCSSの機能」ではない。これらは、ブラウザのネイティブな状態管理システムとCSSスタイリングエンジンを直結させるためのパイプラインである。
無闇にJavaScriptでクラスの付け替えを行ってメインスレッドを圧迫する前に、まずはHTMLのセマンティクスと、CSSの擬似クラスが持つポテンシャルを極限まで引き出すこと。初期表示のバグを `:not(:placeholder-shown)` などのガード条件で巧みにかわし、非同期の壁には `setCustomValidity` で調停役を与える。
この泥臭さと洗練されたアーキテクチャの融合こそが、モダンフロントエンド開発における真の職人芸であり、プロダクトの寿命を延ばす唯一の道なのである。さあ、今すぐあなたのコードベースにある無駄なバリデーション用JSコードを削除し、CSSにその仕事場を返してやろう。
コメント