CSSでバリデーションを制御せよ：`:user-invalid` がもたらす「体験」の解像度
フロントエンドの現場において、バリデーションエラーの表示タイミングほど、エンジニアの美学が問われる場所はない。
かつて我々は、JavaScriptで `blur` イベントを監視し、DOMにクラスを付与し、状態を管理するという泥臭い手法を繰り返してきた。だが、ブラウザの進化はすでにその先にある。`:user-invalid` という疑似クラスの存在は、単なる機能追加ではなく、宣言的UIの極致と言える。
今回は、この強力な武器を単なる「見た目の変更」で終わらせず、堅牢なアーキテクチャの一部として昇華させるための深層技術を紐解いていく。
—
`:user-invalid` の真価：なぜ今、採用すべきか
`:invalid` と `:user-invalid` の決定的な違いは、「ユーザーがそのフィールドとインタラクションを終えたか」というUXの文脈をブラウザエンジンが解釈しているか否かにある。
`:invalid` を使うと、ページを開いた瞬間に空欄の必須項目が真っ赤に染まる。これはユーザーにとって「まだ何もしていないのに責められている」という最悪の体験だ。一方、`:user-invalid` は、ユーザーが入力し、フォーカスを外し、あるいはその値を確定させた瞬間に初めて発火する。ブラウザの内部状態（`validityState`）をCSSが直接参照することで、JavaScript側の状態管理コストを劇的に削減できるのだ。
堅牢なバリデーション実装のコードパターン
実務レベルで導入する際、単に色を変えるだけでは不十分だ。アクセシビリティを担保し、レンダリング負荷を最小化するコード例を以下に示す。
/
- ユーザーが入力し、不整合が発生した際のみ適用される設計。
- :not(:placeholder-shown)を併用することで、初期表示時の誤検知を二重に防ぐ。
/
input:user-invalid:not(:placeholder-shown) {
border: 2px solid var(–color-error-base);
outline: none;
/
- レンダリング負荷を下げるため、box-shadowによる発光などは避け、
- layoutへの影響が少ないborderやoutlineの変更に留めるのが鉄則。
/
}
/
- エラーメッセージの表示制御。
- 兄弟セレクタを用いて、DOM構造の深さを問わずバリデーション結果を反映させる。
/
input:user-invalid:not(:placeholder-shown) + .error-message {
display: block;
opacity: 1;
transition: opacity 0.2s ease-in-out;
}
.error-message {
display: none;
opacity: 0;
color: var(–color-error-text);
font-size: 0.875rem;
/
- will-changeは安易に使うと合成レイヤーが増え、スマホのメモリを食い潰すため、
- トランジションが不要なら指定しないのが正解。
/
}
パフォーマンスとアーキテクチャ上の注意点
この手法を大規模アプリケーションに適用する際、以下の「落とし穴」を回避しなければならない。
1. レンダリングサイクルの考慮
`:user-invalid` はブラウザのネイティブバリデーションエンジンに依存している。もし `Custom Elements` や複雑なサードパーティ製コンポーネントライブラリを多用している場合、`Shadow DOM` 内部のバリデーション状態が親要素に伝播しないという仕様に直面するだろう。この場合、`ElementInternals` API を活用して、カスタムコンポーネントをブラウザのネイティブバリデーション体系に組み込むのが、最も工学的に正しい解だ。
2. 非同期競合の回避
JavaScript側で `setCustomValidity()` を使った非同期バリデーション（例：サーバー側の重複チェック）を行う場合、CSSの疑似クラスと論理が競合する可能性がある。
ここでの鉄則は、「状態の源泉は一つにする」ことだ。
バリデーションエラーを `data-state` 属性としてDOMに反映させるか、あるいは `setCustomValidity` で動的にエラーを注入することで、CSS側はあくまで「ネイティブバリデーションのステータスを表示する単なるビュー」に徹させるべきだ。
3. メモリ効率の最適化
大量の入力フォームを持つ管理画面などで、`:user-invalid` を乱用すると、ブラウザの再計算コストが無視できなくなる。CSSの擬似クラスセレクタは高速だが、セレクタのパスが長くなればなるほど計算量は増大する。可能な限りフラットなDOM構造を維持し、BEM等の設計手法でセレクタを単一のクラスに絞り込むことを推奨する。
—
最後に：エンジニアとしての「余白」
`:user-invalid` を採用することは、ブラウザの標準機能を信頼するという決断だ。多くのフレームワークは独自のバリデーションロジックをJSで記述したがるが、それは時に「車輪の再発明」であり、ブラウザが持つネイティブな最適化を捨てる行為でもある。
技術選定において、最も優れたコードは「書かないコード」だ。ブラウザが標準で提供するこの強力な疑似クラスを使いこなし、JSのメモリ消費を削り、レンダリングパイプラインを最適化する。それが、我々フロントエンド・アーキテクトが目指すべき、枯れた技術と最新のUXの融合点なのである。
さあ、エディタを開き、無駄な `useState` を一つずつ削除していく作業に取り掛かろうではないか。
コメント