Popover API — ブラウザネイティブツールチップが変えるもの

ツールチップを作った経験があれば分かる。見た目はシンプルなのに、実際のユーザーにデプロイすると問題が噴出する。

Tabでトリガーに入っても表示されない。スクリーンリーダーが2回読むか完全に無視する。マウスを速く動かすとチラつく。Escが効かない。フォーカスが消える。

時間が経つと：イベントリスナーが積み重なり、hover/focus別処理、外部クリック特殊ケース、ARIA属性の手動同期...コードが肥大化する。

ライブラリを使った理由

ポジショニングだけで依存性が正当化されるほど複雑だ。スクロールコンテナ、transform、レスポンシブレイアウトでのツールチップ配置は簡単ではない。

だが本当の問題はアクセシビリティだった。マウスユーザーは即時性を、キーボードユーザーは予測可能性を求める。両方を満たそうとすると遅延とエッジケースが生まれる。スクリーンリーダーでの動作が読まれたり、読まれなかったり、2回読まれたり — 非一貫的。

ARIA属性を1つ見落とすとアクセシビリティツリーが混乱する。コードが間違っていたのではなく、プラットフォームに適切なプリミティブがなかった。

Popover API

<button popovertarget="tip-1">ヘルプ</button>
<div id="tip-1" popover="manual" role="tooltip">
  ツールチップの内容
</div>

これだけ。イベントリスナーなし。状態追跡なし。JavaScriptからのARIA更新なし。

フォーカスすると表示、Escを押すと消える。

何が変わるのか

開閉 — ブラウザがHTMLだけで処理する。トリガーとツールチップの関係がマークアップに明示的に存在。

Escキー — キーリスナーを追加していないのに動作する。ブラウザがpopoverの解除可能性を自ら理解。

aria-expanded — popoverの開閉に応じて自動更新。手動管理不要、古い状態が残るリスクもない。

フォーカス復元 — popoverが閉じるとトリガーにフォーカスが自動復元。フォーカス復元コードは追加したのではなく削除した。

コード削減より重要なのは責任の転換だ。以前はJavaScriptが「存在させていた」ツールチップが、今はブラウザがマークアップ上の役割を理解し、フォーカスモデル、アクセシビリティツリー、ネイティブ解除ルールに参加する。

Invoker Commands

popovertarget="id"がボタンをpopoverに接続し、popovertargetactionで動作を指定する。

• show — 開くだけ

• hide — 閉じるだけ

• toggle（デフォルト）— 開いていれば閉じ、閉じていれば開く

1つのツールチップに複数のトリガーを接続できる。

まだ足りない領域

タイミング制御 — ネイティブpopoverは即座に開閉する。マウスの素早い動きやトリガーをかすめると点滅する。hover/focusと表示の間のディレイはまだJavaScriptが必要。

ホバーインテント — ブラウザはホバーが意図的か、ポインターが通過中かを判断できない。非表示前の短いディレイ、ポインターがツールチップに移動時の解除キャンセルはJavaScriptの領域。

popover="manual"のフォーカス — autoと違い、manualではフォーカスの自動復元がない。blurで閉じる時はトリガーへ明示的にフォーカスを返す必要がある。

ライブラリが有効な場合

大規模デザインシステムでは集中化された動作、一貫したデフォルトのためにライブラリが合理的。ネストされたスクロールコンテナやカスタムフリッピングロジックのような複雑なポジショニングにはFloating UIのようなツールが依然有利。

CSS anchor positioningがこの問題のかなりの部分をカバーし始めている。純粋CSSでトリガー基準の相対配置、ビューポート認識配置、エッジフリッピングが可能になりつつある。Interopに含まれ完全なクロスブラウザサポートの見通しがある。

デフォルトがネイティブAPIに移行中だ。最もシンプルなツールチップが同時に最も正確なツールチップになり得る初めての時点。