z-indexの奪い合いに終止符――Popover APIとCSS Anchor Positioningは『JS依存の10年』を終わらせるのか

公開前の下書きです。事実確認と編集を終えていますが、公開・SNS投稿はまだ行っていません。

ドロップダウンメニューを開いたら、固定ヘッダーの下に隠れて見えなくなった。モーダルの上に別のツールチップを重ねたら、どちらが手前に来るか分からずz-index: 9999を書き足す。親要素にoverflow: hiddenが付いているせいで、ツールチップがはみ出た部分だけ切れてしまう――こうした「重ね順の奪い合い」は、Web制作の現場で10年以上、floating-uiのようなJSライブラリが尻拭いをしてきた領域だ。

この状況に、ブラウザ標準機能が手を伸ばし始めている。Popover API（popover属性・popovertarget属性）とCSS Anchor Positioning（anchor-name・position-anchor・anchor()関数など）だ。前者はHTMLだけで「最前面に出る・外側クリックやEscキーで閉じる・（既定のautoモードでは）他のポップオーバーを自動で閉じる」UIを宣言的に作れる仕組み、後者はある要素を別の要素（アンカー）に相対配置する仕組みである。組み合わせれば、「ボタンの右下にツールチップを吸い付かせる」といったUIを、JavaScriptを1行も書かずに構築できる。

結論：Popover APIとCSS Anchor Positioningは、それぞれ別の時期にBaseline「Newly Available」（主要ブラウザ全エンジンで対応したばかりの段階）へ到達した。z-indexの奪い合いを「top layer（最前面レイヤー）」という仕組みで原理的に解消し、フォーカス管理やEscキー対応をブラウザの既定動作に任せられる価値は大きい。ただし「Widely Available（広く行き渡った状態）」にはまだ遠く、複雑なUIは依然JSが必要で、アクセシビリティも自動では完成しない。新規プロジェクトは標準機能を軸にしつつ、既存プロジェクトは部品の単純さで移行の優先順位を決める、という段階的な判断が今日の現実解になる。

Baseline到達は「同時」ではない

編集部の議論の冒頭、ナオ（Web標準を取材する技術記者）が最初に釘を刺したのはここだった。

「同時にBaseline入りした」という認識は誤りです。Popover APIは2025年に、CSS Anchor Positioningは2026年1月に、それぞれ個別に「Newly Available」となりました。

MDNの該当ページで確認できる状況を整理すると、次のようになる。

項目	Popover API	CSS Anchor Positioning
Baseline状況	Newly Available（2025年）	Newly Available（2026年1月〜）
Firefoxの対応	バージョン125（bug 1866993で既定有効化）	2026年初頭のバージョンで対応し、これでBaseline到達
Chrome/Edge/Safari	既に対応済みだった	Chrome/Edgeはバージョン125（2024年）、Safariはバージョン26
Widely Availableか	未到達（正確な移行時期はMDN未確認）	未到達
細部の差	―	`@position-try`（画面端でのフォールバック配置）などはブラウザ間で対応バージョンに差が残る

注記: 表はMDNの実ページ表示とW3C仕様を基にした編集部の整理。「両方とも同時にBaseline入りした」「長年安定して使われている」という書き方はどちらも誤りである。

テツオ（事実確認を担う編集者）は議論の中で、この区別を数値でも補強した。

ブラウザのメインスレッドの計算負荷という観点でも、CSS Anchor Positioningによる配置はブラウザのコンポジット層で処理されるため、従来のJSによる配置計算より負荷が劇的に低減されます。

これは推論を含む技術的な期待だが、少なくとも「Newly Available」という段階自体は事実として確定している。

z-indexとフォーカス管理を「既定動作」に譲る

なぜこの2つの仕様が「JSライブラリへの依存」という文脈で重要なのか。ハルト（デザインシステムを保守するフロントエンド開発者）は、floating-ui等のJSライブラリが担ってきた役割を次のように振り返った。

JSライブラリ（floating-ui等）は、あらゆる環境で「常に同じ挙動」を保証するために存在してきました。

具体的には、z-indexの管理、外側クリックでの閉じる処理、Escキーでの終了、スクロール追従、フォーカスのトラップといった処理を、開発者がJSで再実装するのが定番だった。Popover APIは、要素を「top layer」という専用のレイヤーに移動させることで、z-indexの数値をいくら積んでも解決できなかった重ね順の問題を、原理的に解消する。CSS Anchor Positioningは、この重なった要素を「どのボタンに、どちら向きに」配置するかを、ブラウザのレイアウトエンジンに直接記述できるようにする。なお、Popover APIは非モーダルの仕組みであり、モーダルダイアログのようにフォーカスを内部へ閉じ込める（トラップする）挙動までは提供しない。フォーカスの閉じ込めが必要な場面は、<dialog>要素のshowModal()が担う領域である。

ミサ（Webアクセシビリティの研究者）は、この変化をアクセシビリティの観点から評価した。

Popover APIが提供する「最前面レイヤーへの移動」や「Escキーでの閉じる動作」といった、これまでJSで苦心して実装してきた「アクセシビリティの基盤動作」がブラウザの既定動作として組み込まれた価値は計り知れません。

実装の複雑さから解放されることで、開発者は配置の計算ではなく、適切なラベル付けやフォーカス管理といった、より高度な設計に注力できる余地が生まれる、というのがミサの見立てだ。

反論1：Newly Availableは「安心して使える」ではない

議論が機能紹介だけで終わらなかったのは、ここからの反論があったからだ。ハルトは、デザインシステムを保守する立場から「機能の断片化」を懸念した。

特に懸念されるのは、@position-tryのようなフォールバック制御の挙動差です。標準機能へ移行する場合、古いブラウザへのポリフィル導入や、画面端での配置ロジックの再検証という、膨大なテストコストが伴います。

レン（SaaSプロダクトの技術責任者）も、本番採用の判断者として同様の慎重さを示した。

本機能は「Newly Available」であり、全てのユーザーが恩恵を受けられる「Widely Available」な状態ではありません。そのため、既存プロジェクトではポリフィルを導入して挙動を補完するコストが発生します。

初学者の視点を代弁する形で、カナ（CSSを教えるプログラミング講師）はこの技術者間のやり取りに率直な疑問をぶつけた。

「標準だから安心」と思ってコードを書いたのに、実はブラウザによって動きが違って、結局JSを書き直す羽目になる…なんてことが起きるなら、結局今まで通りライブラリを使う方が楽なんじゃないかな

さらに、標準仕様そのものが将来変わる可能性についても踏み込んだ。

もし将来、その「標準」の使い方がブラウザのアップデートでまた変わっちゃったりしたら、また最初から全部やり直しになっちゃうんですか？

この問いに対し技術責任者のレンは、Popover APIが2025年に、CSS Anchor Positioningが2026年1月にそれぞれ実装を経てBaselineへ到達したことを踏まえ、「実装が覆るリスクは極めて低い」との見解を示した。標準仕様は仕様策定プロセスを経て確定するため、JSライブラリのメジャーアップデートによる破壊的変更とは性質が異なる、という主張である。ただしこれは参加者の推論であり、確定した保証ではない。

反論2：複雑なUIにはまだJSが要る

もう一つの限界は、UIの複雑さそのものだ。ネストしたメニューや高度な状態管理を伴うコンポーネントは、Popover APIとCSS Anchor Positioningだけでは完結しない。技術責任者のレンはここで、実務上の判断基準を提示した。

私の判断基準は「UIの重要度と複雑性」です。単純なツールチップなら標準機能を採用し、ライブラリの更新コストを削減します。一方で、高度な制御が必要な複雑なメニューは、あえてJSライブラリを継続利用します。

デザインシステム保守を担うハルトも同様に、「部品の粒度」という言葉でこれを整理した。

ツールチップなどの単純な部品は、標準機能を用いて「壊れにくい基盤」を構築すべきです。一方で、高度な状態管理を伴う複雑なコンポーネントについては、まだJSによる制御が現実的です。

つまり「JSライブラリが不要になる」という単純な置き換えではなく、UIの部品ごとに標準機能とJSライブラリを使い分ける、という段階的な移行像が議論の到達点になっている。

「標準化＝自動でアクセシブル」ではない

アクセシビリティ研究者のミサが繰り返し強調したのは、標準機能への移行がアクセシビリティを自動的に解決するわけではない、という点だ。

ここで重要なのは「標準化＝自動的なアクセシビリティの完成」ではないという点です。ARIA属性による適切なラベル付けや、コンテキストに応じたフォーカス移動の制御は、依然として開発者の責任であり、標準機能がそれを肩代わりしてくれるわけではありません。

Popover APIが提供するのは「閉じる」「最前面に出る」といった基盤的な既定動作であって、そのポップオーバーが何を表しているか、キーボード操作でどこにフォーカスが移るべきかは、依然として開発者がラベルとマークアップで示す必要がある。この点は、標準機能を採用したからといって手を抜いてよい部分ではない。

事業者・講師それぞれの視点

ソラ（Web制作を発注する事業者代表）は、ライブラリ削減がもたらす保守コストの変化に注目した。

JSライブラリに頼ることは、常に「ライブラリの脆弱性対応」や「バージョンアップに伴う改修」という、目に見えにくい継続的な保守コストを抱えることを意味していました。

一方でソラも、現状が「Newly Available」段階であることは認めたうえで、「新規案件では標準を軸に設計しつつ、既存案件ではどこまでを標準に置き換え、どこまでをJSで守るかの投資対効果を冷静に見極める」ことを現実的な解として挙げた。

講師のカナが投げかけた学習面での意味については、議論の中で「JSなしでここまでできる」ことが初学者の学習曲線を緩やかにする可能性が語られたが、これは議論内の推論であり、教育効果を検証したデータが確認されたわけではない。

AIがUIコードを生成する時代の論点（推論）

議論の後半では、AIがコードを生成する時代における標準仕様の価値という論点も出た。これは検証済みの事実ではなく、参加者の推論として扱う。

特定のライブラリの書き方を学習させるより、標準的なHTML/CSSを学習させる方が、生成されるコードの汎用性と移植性は圧倒的に高まるはずです（事業者代表のソラ）

標準のHTML/CSSであれば、生成されたコードが環境に依存せず、そのまま動作する「セーフティネット」になる（技術責任者のレン）

フレームワーク固有の書き方はバージョンやライブラリの選択に依存するが、標準HTML/CSSはブラウザが解釈する共通の土台であるため、AIが生成したコードの移植性が高まりやすい、という推測だ。この論点自体は検証可能な事実ではなく、今後の動向を見る視点として記録するにとどめる。

読者が持ち帰るべき判断基準

議論を踏まえると、今日の判断基準は次のように整理できる。

新規プロジェクト
  → 単純なツールチップ・メニュー・通知UIは
    Popover API + CSS Anchor Positioningを第一選択に
    （JSライブラリへの依存とバンドルサイズを最小化）
  → ネストしたメニューや高度な状態管理が要るUIは
    引き続きJSライブラリを検討

既存プロジェクト
  → 「UIの部品の単純さ」を基準に優先順位を付ける
    単純な部品から順次、標準機能へ置き換える
  → 古いブラウザ利用者を切り捨てるかどうかは
    ポリフィルの検証コストとJSライブラリの保守コストを比較して判断
  → どちらの場合も、ラベル付け・フォーカス順序の設計は
    標準機能を使っても開発者の責任として残る

図は議論から導いた編集部の整理であり、特定の製品やチームの公式な移行手順を示すものではない。

デモ：JSなしで動く3種のUIと、ボタンに吸い付くツールチップ

デモを開くでは、popover属性・popovertarget属性だけで動くメニュー・情報ポップオーバー・通知風UIの3種と、anchor-name・position-anchorでボタンに相対配置されるツールチップを、実際に操作しながら確認できる。ページ内のJavaScriptは、お使いのブラウザがPopover APIとCSS Anchor Positioningに対応しているかどうかを検出してバッジ表示するためだけに使われており、UIの開閉・重ね順・配置そのものはHTML/CSSだけで動いている。CSS Anchor Positioningに未対応のブラウザで開いた場合は、ツールチップが画面中央付近に固定表示される代替表示になり、その旨も画面上に案内される。

出典を読むときのポイント

MDN「Popover API」：Baseline 2025 Newly Availableの表示と、popover属性・popovertarget属性の仕様を確認した一次資料。
MDN「anchor-name」：Baseline 2026 Newly Available（2026年1月〜）の表示を確認した一次資料。
Bugzilla bug 1866993：FirefoxがPopover APIを既定で有効化した経緯を追跡したトラッキングバグ。
W3C「CSS Anchor Positioning Module Level 1」：anchor-name・position-anchor・anchor()関数の仕様本体。
W3C公式ニュース「CSS Anchor Positioning Module Level 2 FPWD」：Level 2が最初の公開草案段階にあることを確認した公式アナウンス。