こんにちは。フロントエンドの最前線で、日々DOMのうねりとCSSOMのパフォーマンスチューニングに格闘しているチーフアーキテクトの私だ。
モダンなWebアプリケーション開発において、フォームの状態管理は永遠の課題だ。ReactやVue、あるいはSvelteといった現代的なフレームワーク全盛の時代であっても、最終的なレンダリングの担保とピクセルの描画を司るのは、依然としてブラウザのレンダリングエンジンである。
今回は、数ある擬似クラスの中でも、一見地味ながら極めて強力な `:read-only` に焦点を当てよう。
「ユーザーが編集できない状態の要素を選択する」という基本仕様の裏で、ブラウザエンジンがどのようにこのセレクタを評価し、巨大なDOMツリーの中でどうメモリとCPUを消費しているのか。そして、実務で遭遇する「非同期な状態変化との競合」をどういなすべきか。泥臭い実戦の知見とともに、深く潜っていくとしよう。
—
1. なぜ今、`:read-only` なのか：仕様の深い理解とDOMの現在地
まず、`:read-only` の正確な定義をおさらいしておこう。W3Cの仕様書やMDNを読むと「`readonly`属性を持つ入力欄や、そもそも編集不可な要素にマッチする」と書いてある。しかし、実務でこれを扱う上級エンジニアが知るべきは、「何がマッチして、何がマッチしないのか」の境界線だ。
実は、デフォルトで編集できない `div` や `span` などの一般的な要素は、ブラウザによっては `:read-only` にマッチしないケースがある。厳密には、`input`、`textarea`、あるいは `contenteditable=”false”` が設定された要素など、「本来は編集可能になり得るが、現在は読み取り専用に制限されている」文脈の要素こそが、この擬似クラスの主たるターゲットなのだ。
さらに、ここで混同しやすいのが `:disabled` との関係性だ。
多くの開発者が「無効化された要素（`:disabled`）」も `:read-only` に含まれると考えがちだが、CSSの仕様上、`:disabled` な要素は `:read-only` には含まれない（あるいは、ブラウザの実装によって挙動が微妙に異なるグレーゾーンが存在する）。ここを曖昧にしていると、デザインシステムを構築した際に「無効化されたはずの入力欄に、読み取り専用用のスタイルが漏れ出す」という、地味だが致命的なCSSの意図せぬ競合（Specificityの迷宮）に足を踏み入れることになる。
—
2. レンダリング負荷とセレクタの最適化：ブラウザの視点
ここで、少しギークな話をしよう。ブラウザがCSSをどのようにパースし、どの要素にどのスタイルを適用するかを決める「スタイリング計算（Style Calculation）」の内部挙動を想像したことはあるだろうか？
`:read-only` は、動的な状態変化（State）に依存する擬似クラスだ。つまり、JavaScriptによって動的に `readonly` 属性が付与されたり外されたりするたびに、ブラウザはDOMノードのフラグを再評価し、影響を受けるサブツリーのスタイルを再計算（Recalculate Style）する。
数千件のレコードを持つ巨大なデータグリッド（スプレッドシート風のUIなど）を想像してほしい。すべてのセルが `input[readonly]` で構成されている場合、一括で編集モードに切り替える（`readonly` を外す）操作を行った瞬間、ブラウザのメインスレッドで何が起きるか。
- セレクタのマッチングコスト:
汎用的な `:read-only` をセレクタの左側に深く配置すると、ブラウザのセレクタ評価エンジン（BlinkのCSS Selector Matchingなど）は、DOMツリーを走査する際に余計なコストを支払うことになる。
- レイアウトスラッシングの回避:
「読み取り専用だからといって、安易に重いCSSプロパティ（複雑なbox-shadowや、親を巻き込むようなレイアウト変更）を `:read-only` に紐づけていないか？」という問いが重要だ。
実務で使える：堅牢なスタイリングパターン
無駄な再描画を防ぎ、メモリ効率とレンダリング速度を極限まで高めるためのCSSアーキテクチャの例を見てみよう。
/ =================================================================ate
High-Performance Form Control Architecture
Target: Enterprise-grade Web Application
=================================================================== /
/ 1. ベースの入力フィールド（高頻度で再描画されるためプロパティは最小限に） /
.app-input {
box-sizing: border-box;
padding: 0.5rem 0.75rem;
font-size: 1rem;
border: 1px solid var(–color-border-base);
background-color: var(–color-bg-editable);
color: var(–color-text-primary);
transition: border-color 0.15s ease-in-out; / トランジションは必要最小限のプロパティに絞る /
}
/ 2. 編集可能な状態でのフォーカス時（GPUアクセラレーションを意識した省コスト設計） /
.app-input:focus:not(:read-only) {
outline: none;
border-color: var(–color-primary);
box-shadow: 0 0 0 3px var(–color-primary-alpha);
}
/ 3. :read-only を用いた読み取り専用状態のスタイリング
重要: :disabled との明確な分離を行い、スタイルが漏れ出さないようにする /
.app-input:read-only:not(:disabled) {
background-color: var(–color-bg-readonly);
border-color: transparent; / 枠線を消すことで、視覚的なノイズを減らしレンダリング負荷も微減させる /
color: var(–color-text-muted);
cursor: default;
/ リサイズや不要なインタラクションを完全に遮断 /
resize: none;
}
/ 4. アクセシビリティとフォーカスの制御
読み取り専用であっても、キーボードナビゲーションでフォーカスが当たる場合の対策 /
.app-input:read-only:focus {
outline: 1px dashed var(–color-text-muted);
outline-offset: -1px;
}
このコードの肝は `:read-only:not(:disabled)` というセレクタの組み合わせにある。これにより、システムが意図しない「無効化された要素」と「意図的に読み取り専用にされている要素」のスタイルの衝突を、CSSの段階で完全にシャットアウトしているのだ。
—
3. 非同期の競合とフレームワーク間（React/Vue）の罠
実務の現場で最も頭を悩ませるのが、「非同期データフェッチの完了とDOMの属性付与のタイミングのズレ」だ。
例えば、SPA（Single Page Application）において、APIからユーザー権限を取得し、その結果に応じてフォームを `readonly` に切り替えるシチュエーションを考えてほしい。
1. コンポーネントがマウントされる（この瞬間、初期値として `readonly` はついていない）。
2. 非同期でAPIリクエストが走る（数百年〜数千ミリ秒のラグ）。
3. レスポンスが返り、状態（State）が更新され、DOMに `readonly` 属性がバインドされる。
この「非同期の空白期間」に、ユーザーがすかさず入力欄にフォーカスして文字を入力し始めたとする。Reactの仮想DOMの差分検出と実際のDOMへの反映の間にわずかなタイムラグが生じ、CSSの `:read-only` が適用される前にユーザーがタイピングを完了してしまうという、いわゆる「競合状態（Race Condition）」が稀に発生する。
アーキテクトとしての処方箋
CSSの `:read-only` はあくまで「見栄えと簡易的なガード」に過ぎない。堅牢なWebアプリケーションを目指すならば、CSSとJavaScriptの責務を厳格に分離し、二重の防御壁を構築しなければならない。
- CSS側 (`:read-only`): 視覚的なフィードバック（「ここは触れませんよ」というユーザーへの伝達）を高速に行う。
- JS/フレームワーク側: 実際のイベントハンドラ（`onInput`, `onKeyDown` など）の内部で、確実にガード条件を評価する。
さらに、CSS側で以下のようなハックを組み合わせることで、意図しないインタラクションを物理的に封殺することも可能だ。
/ 読み取り専用要素に対するマウスイベントの完全無効化
注意: これを行うとテキストの「選択・コピー」ができなくなるトレードオフがあるため、要件と要相談 /
.app-input.is-strict-readonly:read-only {
pointer-events: none;
}
テキストのコピーを許可しつつインタラクションだけを制限したいのか、あるいは完全に不活性なオブジェクトとして扱いたいのか。プロダクトの要件定義の深層まで踏み込み、CSSのプロパティをチョイスするのが、真に優秀なフロントエンド・アーキテクトの仕事である。
—
4. デバッグとパフォーマンス最適化の極意
最後に、もしあなたが「なんかこのページのフォーム入力がもっさりするな……」と感じたときに、どうやって `:read-only` に起因するパフォーマンスボトルネックを炙り出すかの実践的な知見を授けよう。
1. Chrome DevTools の Performance タブを開く
フォームの状態を一斉に切り替えるアクションを記録（Record）し、「Recalculate Style」や「Layout」に費やされている時間をチェックする。
2. CSS Selector Profiler の活用
もし特定の `:read-only` を含む複雑な子孫セレクタ（例: `.form-container .section .row input:read-only`）がスタイリングのボトルネックになっている場合、ブラウザはDOMツリーの深くまで走査を強いられている。
3. セレクタの平坦化（Flattening）
可能な限り、セレクタのネストを浅くし、クラスベースまたは直接の属性セレクタに寄せることで、ブラウザのスタイルマッチングのアルゴリズム（Right-to-Left Matching）の負荷を劇的に軽減できる。
/ 良い例：右から左へのマッチングが高速に終わる /
input:read-only.app-input {
/ styles /
}
/ 避けるべき例：深い子孫セレクタは大規模アプリでパフォーマンスの悪夢になる /
.main-layout .content-wrapper form fieldset div input:read-only {
/ styles /
}
—
総括
たかが `:read-only`、されど `:read-only` だ。
表面的な使い方を覚えるだけなら数分で終わるが、その背後にあるブラウザエンジンの挙動、フレームワークの非同期処理とのマリアージュ、そして大規模アプリケーションにおけるメモリ効率とレンダリング最適化まで意識を巡らせれば、CSSは単なる「デザインツール」から、「堅牢なアプリケーション基盤を支えるシステムコード」へと昇華する。
日々のコーディングにおいて、ただ動くものを作るのではなく、「なぜそのセレクタでなければならないのか」「ブラウザにどれだけの負荷を与えているのか」を常に自問自答し続けてほしい。その泥臭い探求心の積み重ねこそが、あなたを真のフロントエンド・スペシャリストへと導く唯一の道なのだから。
コメント