【実務・中級編】 :blank 擬似クラス（草案） – CSS実践ガイド

CSSの「幻の擬似クラス」 `:blank` と現実的なUI実装の落とし所

フロントエンドの深淵に足を踏み入れている君なら、一度は思ったことがあるはずだ。「フォームに入力された値が空、あるいは空白文字だけの場合に、スタイリングを制御したい」と。

CSSには `:empty` という擬似クラスが存在するが、これは「DOM的に完全に子要素を持たない（テキストノードすら存在しない）」要素にしか反応しない。インデントや改行が混じったHTMLや、JavaScriptで動的に値が挿入される現場の泥臭いフォーム環境では、ほぼ役に立たないのが現実だ。

そこで登場するのが `:blank` だ。しかし、これがまた厄介な代物でね。今日はこの「幻の存在」の正体と、我々が明日からの現場でどう立ち回るべきかを語ろう。

—

`:blank` とは何か、そしてなぜ「使えない」のか

CSS仕様書における `:blank` の定義は明確だ。「空白文字（スペース、タブ、改行など）のみを含む要素を選択する」というもの。

もしこれが実装されていれば、ユーザーがフォームの入力をサボってスペースだけを入力した際に、即座にエラー表示を出すといった制御がCSSだけで完結する……はずだった。だが、現実のブラウザ実装状況は、「実質的に無視していいレベル」だ。

ブラウザサポートの現在地: ほぼ全滅だ。Firefoxがかつて実験的に実装していた時期もあったが、主要ブラウザの足並みは揃っていない。
なぜ実装されないのか: ブラウザベンダーにとって、レンダリングエンジン側で「何をもって空白とみなすか」の定義が複雑すぎる。さらに、セキュリティやアクセシビリティの観点から、フォームのバリデーションは「CSSの見た目」に依存させるべきではないという強力な設計思想が働いているんだ。

結論を言うと、「`:blank` を本番環境のCSSに書くのは、まだ早い」。 これを信じてコードを書くと、デバッグ地獄に直面することになる。

—

現場で「空白判定」をどう突破するか？

`:blank` が使えない以上、我々はJavaScriptの力を借りるしかない。しかし、ただ実装するのではなく、CSSの設計思想を活かした「美しい運用」を心がけよう。

ここでのベストプラクティスは、「JavaScriptで状態（クラス）を付与し、CSSでスタイリングする」という基本に立ち返ることだ。

実装サンプル：JavaScript × CSS の現実的な解

以下は、入力値が空、あるいは空白のみの場合にスタイルを変化させる実務的なパターンだ。

/ CSS側：状態を管理するクラスを定義 /
.input-field {
border: 1px solid #ccc;
transition: border-color 0.2s;
}

/ JavaScriptが付与するユーティリティクラス /
.is-blank {
border-color: #ff4d4f; / エラー時は赤くする /
}

// JS側：イベント監視と判定
const input = document.querySelector(‘.input-field’);

input.addEventListener(‘input’, (e) => {
const value = e.target.value;

// trim()を使って、空白文字のみか判定する
// これが現場で最も確実な「空白判定」のロジックだ
if (value.trim() === ”) {
input.classList.add(‘is-blank’);
} else {
input.classList.remove(‘is-blank’);
}
});

—

なぜこれが「プロのコード」なのか

わざわざJSを使う理由は、単にブラウザが対応していないからだけではない。

1. 判定の確実性: `trim()` を使えば、タブ文字や全角スペース（必要に応じて正規表現でケアする）も一網打尽にできる。CSSの擬似クラスに依存するよりも、ロジックとして堅牢だ。
2. アクセシビリティの担保: フォームが「空である」という状態は、単に見た目を変えるだけでなく、スクリーンリーダーへ `aria-invalid=”true”` を伝える必要がある。CSSの擬似クラスだけでは、このUIアクセシビリティの担保ができないんだ。
3. 移植性: 今後、もし将来的に `:blank` が標準化されたとしても、CSS側のクラス定義を変えるだけで済むようにしておけば、リファクタリングコストは最小限で済む。

まとめ：理想と現実のバランス感覚

`:blank` は非常に魅力的な仕様だが、現代のフロントエンド開発において「まだ標準化されていない未来の機能」に頼るのは、プロジェクトのリスクを高めるだけだ。

現場で大切なのは、「仕様書を鵜呑みにせず、今使える最強の手段を組み合わせて、最大限のパフォーマンスと保守性を引き出すこと」。

今回のJSによる実装は、泥臭いように見えて、実は最も拡張性が高く、あらゆるブラウザで同じ挙動を保証できる「銀の弾丸」だ。まずはこのアプローチを手に馴染ませておいてくれ。次世代のブラウザが追い付いてきたとき、その時に初めて、コードを綺麗に掃除して `:blank` へと移行すればいいのさ。

技術は常に移り変わる。だが、論理的な設計思想さえ持っていれば、どんな環境でも戦えるはずだ。期待しているよ。