【テクニカル・上級編】 target疑似クラス – CSS実践ガイド

`:target` 疑似クラス：URLの断片が織りなす、JavaScriptレスなDOMステート管理の極意

こんにちは。日々ブラウザのレンダリングパイプラインとメモリ消費の最適化に頭を悩ませているフロントエンド・アーキテクチャの住人なら、一度はこう考えたことがあるはずだ。

「なぜ、ちょっとしたモーダルやタブの切り替えごとのために、わざわざ数キロバイトのJavaScriptを持ち出し、仮想DOMの差分検出コストを支払わなければならないのか？」と。

現代のWeb開発において、状態管理（State Management）といえばReactの`useState`やZustand、あるいはVueのComposition APIがデファクトスタンダードだ。しかし、ブラウザが標準で備えているプリミティブな機能、特にURLのハッシュ（フラグメント識別子）と連動する `:target` 疑似クラスを適切に調教すれば、JavaScriptを一切書かずに、堅牢かつ超高速なUIステートマシンを構築できる。

今回は、この古くて新しい `:target` 疑似クラスにスポットを当て、ブラウザの内部挙動、メモリ効率、そして実務の現場で踏み抜きがちな地雷の回避策まで、徹底的に深掘りしていこう。

—

1. `:target` の基本メカニズムとブラウザエンジンの内部挙動

`:target` は、URLのハッシュ（例: `https://example.com/#section-a`）が、現在の文書内の要素の `id` 属性と一致した瞬間にその要素にヒットする動的な疑似クラスだ。

一見すると、単なるアンカーリンクのスタイリング機能に見えるかもしれない。しかし、ブラウザエンジンのライフサイクルの観点から見ると、これは「URLの変更をトリガーとしたネイティブなステート管理機構」に他ならない。

レンダリングと再描画の最適化

JavaScriptで状態を切り替える場合、以下のようなコストが発生する。
1. イベントリスナーの発火
2. ステートの更新
3. 仮想DOMの構築と差分計算（Reconciliation）
4. 実DOMのパッチ適用
5. ブラウザによるスタイル計算（Recalculate Style）とレイアウト/ペイント

一方、`:target` を用いた場合、ハッシュの変更によるURLの書き換わりはブラウザの履歴（History API）と直接結びついており、スタイル計算エンジンはDOMツリー全体を再走査することなく、該当する要素とその周辺のセレクタマッチングのみをピンポイントで評価できる。C++で書かれたブラウザの内部コード（BlinkやGecko）において、ハッシュ変更時のセレクタキャッシュのヒット率は非常に高く、無駄な再レイアウトを劇的に削減できるのだ。

—

2. 実践：JSレスで構築するタブ＆モーダル・アーキテクチャ

百聞は一見にしかず。実務の現場で即座に応用できる、`:target` を活用したタブ切り替えとモーダルのコンポーネント設計を見てみよう。ここではアクセシビリティ（a11y）とメモリ効率を極限まで高めたパターンを提示する。

このコードの美しさは、「状態の保持場所がURLというグローバルなステートストアに完全に委譲されている」点にある。ユーザーがページをリロードしようとも、ブラウザバックしようとも、UIの状態は完璧に復元される。SPAのルーターライブラリが裏でやっていることを、CSSとブラウザのプリミティブな機能だけで極限までシンプルに実装しているのだ。

—

3. 上級者が陥る罠：`:target` 活用の落とし穴と回避策

しかし、実務の現場において `:target` を無思考で導入すると、いくつかの重大なアーキテクチャ上の問題に直面する。シニアエンジニアとして、その「地雷」と回避策を共有しておこう。

意図しない画面のスクロールジャンプ（Jank & Jump）

`:target` の本来の仕様は、「該当するIDの要素へ画面をスクロールさせる」ことだ。
これが曲者で、ユーザーがタブをクリックしたりモーダルを開いたりした瞬間、ブラウザは容赦なくその要素へとビューポートを強制スクロールさせる。モーダルが画面外にある場合、画面がガクッと意図しない位置に動いてしまう。

【回避策】CSSの `scroll-behavior` とレイアウトの分離
現代のCSSであれば、`overflow` や `scroll-margin`、あるいは `position: fixed` を駆使してスクロールジャンプを完全に無力化できる。

/ ターゲットになった際の強制スクロールを無効化、または親要素で封じ込める /
.modal-overlay {
position: fixed;
/ ビューポート全体をカバーし、背後のスクロールを完全に防ぐ /
top: 0; left: 0; width: 100vw; height: 100vh;
}

また、どうしてもスクロールさせたくない場合は、JavaScriptで `preventDefault()` を挟むか、CSSの `scroll-margin-top` を調整してジャンプ量を相殺するテクニックもあるが、純粋なCSSだけで完結させたい場合は「オーバーレイ要素を固定配置し、その子孫に `:target` を置く」構造にするのが最も堅牢である。

履歴（History）の汚染問題

`:target` を切り替えるたびに、ブラウザの履歴（`history.pushState` 相当の挙動）にハッシュが蓄積されていく。結果として、ユーザーが「前のページに戻ろう」とブラウザの「戻る」ボタンを押した際、Webサイトの前のページではなく、直前に開いていたタブやモーダルが一つずつ閉じるという、ユーザーにとって非常にストレスフルな挙動を生む。

【回避策】`history.replaceState` を活用したマイクロJSの導入
ここで、「完全にJSゼロ」というイデオロギーから一歩引き、実務的なユーザビリティをとるアプローチが必要になる。タブ切り替え程度であれば、クリックイベントをキャッチして `history.replaceState` を使ってハッシュを置換（または管理）するか、そもそも履歴に残したくないUI（モーダルやドロワーなど）に限定して `:target` を採用するという割り切りが重要だ。

// モーダルやドロワーなど、履歴に残したくない場合のマイクロスクリプト
document.querySelectorAll(‘a[href^=”#modal”]’).forEach(anchor => {
anchor.addEventListener(‘click’, (e) => {
// 必要に応じて履歴の挙動をコントロールする
});
});

—

4. まとめ：ネイティブの原点回帰が生む圧倒的な堅牢性

近年のフロントエンド開発界隈は、あらゆるUIの状態をJavaScriptの巨大なステートツリーに閉じ込めようとする傾向がある。その結果、シンプルなタブを1つ作るのにも何重もの抽象化レイヤーを重ね、バンドルサイズを肥大化させ、メインスレッドを圧迫しているケースを散見する。

`:target` 疑似クラスをはじめとするCSSのネイティブな状態管理機能は、レガシーな技術ではない。むしろ、「ブラウザのプリミティブな仕様を深く理解し、適切な箇所に適用する」という、極めてモダンで洗練されたアーキテクチャの選択肢なのだ。

すべてのUIをCSSだけで構築することはできない。しかし、URLのハッシュと連動できるスコープのUI（モーダル、タブ、アコーディオン、ステップフォームなど）においては、`:target` は依然として最強のカードの1つである。

次に「このUIの状態管理、どう設計しようか」と悩んだときは、フレームワークのソースコードを開く前に、URLのハッシュと `:target` の存在を思い出してほしい。そこには、JavaScriptのランタイムから解放された、静けさと圧倒的なパフォーマンスを持つ世界が広がっているはずだ。