ツールチップは、UI に関する問題の中で最も小さいもののように思えます。それらは小さいので、通常は隠れています。構築方法を尋ねられると、ほとんどの場合、何らかの JavaScript ライブラリを使用する従来の答えが返されます。そして長い間、それが賢明なアドバイスでした。 私もそれに従った。 表面的には、ツールチップはシンプルです。要素にマウスを置くかフォーカスすると、テキストが含まれた小さなボックスが表示され、ユーザーが離れるとボックスが非表示になります。しかし、実際のユーザーに提供すると、エッジが見え始めます。キーボード ユーザーは Tab キーを押してトリガーに移動しますが、ツールチップは表示されません。スクリーン リーダーはそれを 2 回アナウンスするか、まったくアナウンスしません。マウスを速く動かしすぎると、ツールチップがちらつきます。小さい画面ではコンテンツが重なって表示されます。 Esc キーを押しても閉じません。集中力が失われます。 時間が経つにつれて、ツールチップのコードは、もう所有したくないものになってしまいました。イベントリスナーが積み重なっています。ホバーとフォーカスは個別に処理する必要がありました。外側のクリックには特殊なケースが必要でした。 ARIA 属性は手動で同期を保つ必要がありました。小さな修正を行うたびに、ロジックの層がさらに追加されました。 ライブラリは役に立ちましたが、舞台裏で何が起こっているのかを完全に理解するのではなく、むしろブラックボックスのようなものでもありました。 それが、私が新しい Popover API に注目するきっかけとなりました。ライブラリを使わずにブラウザーのネイティブ モデルを使用して 1 つのツールチップを再構築するとどうなるかを確認したかったのです。 始めるにあたり、他の新機能と同様に、まだ解決されていない部分があることに注意してください。とはいえ、API 全体には流動的な部分がいくつかありますが、現時点では優れたブラウザー サポートを享受しています。それまでの間、カニウスに注目する価値はある。 「古い」ツールチップ Popover API が登場する前は、ツールチップ ライブラリの使用はショートカットではありませんでした。それがデフォルトでした。ブラウザには、マウス、キーボード、支援技術で機能するツールチップというネイティブの概念がありませんでした。正確さを重視する場合、唯一の選択肢はライブラリを使用することであり、まさに私がそうしました。 大まかに言うと、パターンは常に同じでした。トリガー要素、非表示のツールチップ要素、そして 2 つを調整する JavaScript です。
このライブラリは、ホバーまたはフォーカス時に要素を表示し、ブラーまたはマウスを離れると非表示にし、スクロール時に位置変更/サイズ変更できるようにする配線を処理しました。
時間が経つと、ツールチップが壊れやすくなる可能性があります。小さな変更にはリスクが伴います。マイナーな修正によりリグレッションが発生しました。さらに悪いことに、新しいツールチップを追加すると、同じ複雑さが引き継がれます。技術的にはうまくいきましたが、解決したり完了したとは感じられませんでした。 これが、ブラウザーのネイティブ Popover API を使用してツールチップを再構築することにしたときの状況でした。 Popover APIを試してみた瞬間 何か新しいことを実験したかったので、Popover API の使用に切り替えたわけではありません。ブラウザーがすでに理解しているはずだと信じていたツールチップの動作を維持するのにうんざりしたため、切り替えました。 最初は懐疑的でした。ほとんどの新しい Web API はシンプルさを約束しますが、依然として、回避しようとしていたのと同じ複雑さを静かに再現する接着剤、エッジケース処理、またはフォールバック ロジックが必要です。 そこで、可能な限り最小の方法で Popover API を試してみました。その様子は次のとおりです。
1. キーボードは「正しく動作する」 キーボードのサポートは、複数のレイヤーが正しく並んでいることに依存していました。フォーカスはツールチップをトリガーする必要があり、ブラーはツールチップを非表示にする必要があり、Esc は手動で接続する必要があり、タイミングが重要でした。エッジ ケースを 1 つ見逃すと、ツールチップが長時間開いたままになるか、読み取られる前に消えてしまいます。 ポップオーバー属性を自動または手動に設定すると、ブラウザーが基本を引き継ぎます。Tab キーと Shift+Tab キーは通常どおりに動作し、Esc キーは毎回ツールチップを閉じ、追加のリスナーは必要ありません。
私のコードベースから消えたのは、グローバル キーダウン ハンドラー、Esc 固有のクリーンアップ ロジック、およびキーボード ナビゲーション中の状態チェックでした。キーボード エクスペリエンスは私が維持しなければならないものではなくなり、ブラウザーで保証されるようになりました。 2. スクリーンリーダーの予測可能性 これは最大の改善点。前に概説したように、ARIA の作業を注意深く行ったとしても、動作はさまざまでした。小さな変化はすべてリスクに感じられました。ポップオーバーを適切な役割で使用すると、見た目も感触もはるかに安定し、何が起こるか予測可能になります。
そして、これがもう 1 つの利点です。切り替え後、Lighthouse はインタラクションに対する誤った ARIA 状態の警告にフラグを立てなくなりました。これは主に、私が誤って間違う可能性のあるカスタム ARIA 状態がなくなったためです。
3. フォーカス管理 かつては集中力が脆弱でした。以前は、フォーカス トリガーにツールチップを表示させる、フォーカスをツールチップに移動して閉じない、近すぎる場合はトリガーをぼかす、ツールチップを閉じて手動でフォーカスを復元する、といったルールがありました。これは機能しなくなるまで機能しました。 ポップオーバー API を使用すると、ブラウザーはより自然にフォーカスをポップオーバーに移動できる単純なモデルを強制します。ポップオーバーを閉じるとフォーカスがトリガーに戻り、目に見えないフォーカス トラップやフォーカスが失われる瞬間はありません。また、フォーカス復元コードは追加しませんでした。取り除きました。
結論 Popover API は、ツールチップがシミュレートされるものではなくなったことを意味します。これらはブラウザが理解できるものです。開く、閉じる、キーボードの動作、エスケープ処理、およびアクセシビリティの大部分は、アドホック JavaScript ではなくプラットフォーム自体から提供されるようになりました。 これは、ツールチップ ライブラリが時代遅れになるという意味ではありません。ツールチップ ライブラリは、複雑な設計システム、高度なカスタマイズ、従来の制約には依然として意味を持ちますが、デフォルトは変更されています。初めて、最も単純なツールチップが最も正しいものになる可能性があります。興味があれば、この実験を試してみてください。製品内の 1 つのツールチップだけを Popover API に置き換えるだけで、すべてを書き換えたり、システム全体を移行したりせず、1 つだけを選択して、コードから何が消えるかを確認してください。 プラットフォームがより優れたプリミティブを提供すると、JavaScript の行数が減るだけでなく、心配する必要がまったく減ります。 私の GitHub リポジトリで完全なソース コードを確認してください。 さらに読む ポップオーバーと関連 API について詳しくは、以下をご覧ください。
「ポッピン・イン」 ジェフ・グラハム 「ポップオーバーとダイアログの関係の明確化」、Zell Liew 「ポップオーバー=ヒントとは何ですか?」、ウナ・クラベッツ 「Invoker Commands」ダニエル・シュワルツ 「HTML ポップオーバーを使用した自動終了通知の作成」、Preethi オープン UI ポップオーバー API の説明 「風船を割る」ジョン・レア 「CSS アンカー ポジショニング」、フアン ディエゴ ロドリゲス
MDN は、Popover API に関する包括的な技術ドキュメントも提供しています。
