Dialog と Popover #2

Intro

showModalDialog() は今から考えれば、確かにひどい API だった。

しかし、何か Modal を開き、ユーザにインタラクションをさせ、閉じたらそこで入力された値や選択された結果を取得し、処理を進めたいユースケース自体は、規約への同意取得や、 Cookie バナー、ログインなど多々ある。

そういった場面では、ライブラリなどを用いて実装する必要があったが、 Modal を実装するのは実際にはそんなに簡単ではなかった。

Modal, Dialog, Modal Dialog

最初に、用語を少し整理しておこう。

• Modal
• Dialog
• Modal Dialog
• non-Modal Dialog

Dialog とは、そもそも「対話」という意味であり、 UI の文脈では入力や選択を求める「対話的な UI」のことを指す。

既に実装されている alert(), confirm(), prompt() なども広く言えば Dialog にあたり、同意を求めたり、設定を確認させたり、更新があるから再読み込みさせたりといった用途で使う。

その中で Modal とは一般的には「特定のタスクを行うためのモード」といったニュアンスがあるが、この文脈では「それを処理しない限り先に進めない/他の操作ができない」ようなブロックを伴う UI のことを指す。つまり、 Dialog には 「Modal で出す」か「non-Modal で出すか」という 2 種類があるということだ。(modeless という表現をする場合もあるが、 Open UI では non-Modal という表現が使われている。)

Modal Dialog は Web 以外にも多くのプラットフォームで提供され、コモンケースとして以下のように実装されることが多い。

• Dialog 以外を非活性にし操作(focus, click, scroll)できなくする
• 非活性部分が薄暗くなる
• Dialog を閉じたら、結果の値が呼び出し側に返り、元の処理を再開する

逆に non-Modal な Dialog は、開くだけで他を非活性にしない。

以降単に Modal と言った場合、「Modal で開いた Dialog」つまり「Modal Dialog」のことを指すことにする。

Modal 実装の難しさ

Modal の実装を自前で行うとすれば、見た目としては以下のような要件を満たすことになるだろう。

• 他を差し置いて一番手前(上)に表示される
• そこを処理しない限り次に進めない(他の処理ができない)
• 表示している後ろ(裏)は薄暗くなる
• etc

この UI を実装する CSS を考えると、「画面いっぱいに、広げた <div> を被せ Opacity でフィルターかけて、 Modal 用に z-index を最大にした <div> をセンタリグし、、」などと想像できるかもしれない。

しかし、「頑張ればできそう」なだけで、実際には「使いにくい Modal」が世の中に大量に生み出されてしまった。

例えばよくあるのは、フォーカス管理の欠如だ。

1. Modal を開いてるのに、フォーカスは Modal 外のままで、キーボードで操作したいユーザが Modal に Tab で辿り着けない
2. Modal を開いてて、フォーカスも Modal に乗ってるのに、Tab を押すと Modal から落ちて外に移動してしまう
3. Modal を閉じた際に、以前いた場所とは別の場所にフォーカスが移り迷子になる
4. Modal 上で Tab 移動し、Modal の一番下まで行ったら、次は Modal の上に戻って欲しいが、そのまま外に出て行ってしまう

こうした制御はフォーカストラップと呼ばれ、実装が難しい代表例だ。

他にも、モダールにできて欲しいことができない実装も多い。

1. z-index 戦争に負けて Modal の上に別の何かが表示されている
2. Modal を開いてる時も、 Modal 外をクリックしたりスクロールしたり操作できてしまう
3. Modal 外をクリックしたら Modal を閉じて欲しいのに、閉じてくれない
4. Esc を押したら閉じて欲しいのに、閉じてくれない
5. Modal 以外を暗くするのに失敗して、 Modal も暗くなってる。もしくは変なところだけ暗い/明るい。
6. 最初の Modal を残したまま、同じレベルの 2 個目の Modal を開けてしまう。
7. Modal が開いてること、 Modal 上に移動したこと、 Modal を閉じたことなどが、支援機能に伝わらないので、何が起こったか伝わらないユーザがいる。
8. Modal が開いて、後ろが非活性なのに、そのことが支援技術に伝わらずに、操作できない箇所に引っかかって操作が進められないユーザがいる。
9. etc etc etc etc etc etc

実世界には、こうした細かい挙動を実装できてない、「ただ真ん中に表示されただけの DOM」でしかない Modal モドキも少なくない。

実装パターンは APG にもまとめられてるが、これを自前でやるのも簡単ではない。

• Dialog (Modal) Pattern | APG | WAI | W3C ​
  • https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/

様々な UI ライブラリが Modal Dialog 相当の機能を、 APG を元に提供しているが、それでもやはり理想的な実装は難しい。

というか、残念なことに、どんなに JS や CSS を捏ね回してツギハギしても、ネイティブの支援を得た実装と比較すると、劣化版しか作れないのが実際だ。

だからこそ、この要件を標準化し、ブラウザがネイティブの実装を提供しようということになった。

標準 Dialog

showModalDialog() が問題になったのは 2014 年ごろで、実に 10 年前の話だったが、実はこの頃すでに <dialog> の仕様自体はあった。

とはいえ Chrome が少し実装し、 Opera も先に実装を進め flag の裏に持っていた。 Safari / Firefox は長らく実装していなかった。

HTML5.2 で W3C の方の仕様では消されそうになったこともあるくらい、影の薄い仕様だった。

• CfC: HTML 5.2 to Candidate Recommendation
  • https://github.com/w3c/html/issues/969

ところが、 2016 年ごろ Firefox で再度議論が進み、再度標準化を進めようという話になった。

• Re: Proposal to retain dialog in HTML5.2
  • https://lists.w3.org/Archives/Public/public-html/2017Sep/0005.html

Firefox は内部でも <dialog> を使いたいユースケースがあったという話もあり、実装が進んで 2020 年に Ship されている。

• Intent to implement: HTML5 <dialog> element
  • https://groups.google.com/g/mozilla.dev.platform/c/vTPGW1aJq24/m/JnEnoH3BEAAJ
• Intent to Ship : HTML5 <dialog> element (Nightly Only)
  • https://groups.google.com/g/mozilla.dev.platform/c/gqi4MDQDwX8

Firefox が Ship を進めるのと同時期くらいに、これを現在のように「ぜひ使うべき機能」まで大きく進めたきっかけが Interop だった。

MDN が Developer Survey という大規模調査で、開発者が何に困っているのかを調査し、その結果をブラウザベンダに共有して互換性問題を改善しようということで始まったのが Compat 2021 だが、それが 2022 年に Interop と名前を変えた時に、 Focus Area として <dialog> が採用されたのだ。

• dialog & ::backdrop · Issue #12 · web-platform-tests/interop
  • https://github.com/web-platform-tests/interop/issues/12

それを受け、 Safari が実装することになる。 Igalia の協力もあったらしい。

• Introducing the Dialog Element | WebKit
  • https://webkit.org/blog/12209/introducing-the-dialog-element/

こうして、無事全てのブラウザで使えるようになった。

合わせて、ブラウザ間で微妙に異なる挙動のすり合わせや、足らないプリミティブの整理と仕様化も行われた。

関連仕様

<div inert>
  <p>not selectable</p>
  <button>not clickable</button>
</div>

[inert] {
  background-color: rgba(200,200,200,0.50);
}

::backdrop {
  background-color: rgba(200, 200, 200, 0.50);
}

:modal {
  /* xxx */
}

const watcher = new CloseWatcher();

watcher.addEventListener("cancel", () => {
  console.log("cancel")
});
watcher.addEventListener("close", () => {
  console.log("close")
});

<dialog>

さて、以上の仕様を組み合わせて実現したのが <dialog> 要素だ。

role=dialog の要素であり、以下のような、これまでエンジニアが無理やり実装してきた Modal への要件を、一挙に解決してくれているのだ。

• ネイティブで Modal / non-Modal な Dialog を開くことができる
• Modal を開くと自動で背景が inert になる
• フォーカスの管理や、活性管理などが自動で行われる
• :modal / ::backdrop をスタイルできる
• Close Watcher が実装されている
• aria-modal=true であり、支援技術に伝わる

つまり、支援技術に対しても「Modal Dialog が開いた」ということが伝わる。

もしそれが ARIA で言う Alert (警告)の意味をもっているなら、 role=alertdialog で上書きする必要はあるが、そうでない場合は単に <dialog> を使って実装しているだけで、十分なセマンティクスが提供できるのだ。

open/close ? show/hide ? show/close ?

仕様にも書かれてるが、一般的に

• open / close
• show / hide

という対称性を持たせた操作に命名するのが一般的なのだが、 <dialog> については

• show / close

という操作体系になっており、メソッド名もそうなっている。

この理由は少し面白くて、仕様ではこうかかれている。

We use show/close as the verbs for dialog elements, as opposed to verb pairs that are more commonly thought of as antonyms such as show/hide or open/close, due to the following constraints:

dialog の動詞として、show/hide や open/close のような反対語として一般的に考えられている動詞ペアとは対照的に、以下の制約から show/close を使用する:

Hiding a dialog is different from closing one. Closing a dialog gives it a return value, fires an event, unblocks the page for other dialogs, and so on. Whereas hiding a dialog is a purely visual property, and is something you can already do with the hidden attribute or by removing the open attribute. (See also the note above about removing the open attribute, and how hiding the dialog in that way is generally not desired.)

dialog を hide すことと close することは異なる。 dialog を close することは、その dialog に戻り値を与えたり、イベントを発生させたり、他の dialog のためにページのブロックを解除したりする。一方、 dialog の hide は純粋に視覚的な特性であり、hidden 属性や open 属性の削除で既にできることだ(open 属性の削除と、その方法による dialog の非表示が一般的に望まれていないことについては、上の注釈も参照)。

Showing a dialog is different from opening one. Opening a dialog consists of creating and showing that dialog (similar to how window.open() both creates and shows a new window). Whereas showing the dialog is the process of taking a dialog element that is already in the DOM, and making it interactive and visible to the user.

dialog を show することは、dialog を open することとは異なる。dialog を open することは、dialog を create & show することだ(window.open() が新しいウィンドウを作成し表示するのと同様)。一方、dialog を show することは、すでに DOM にある dialog 要素を、インタラクティブにユーザーに見えるようにすることだ。

If we were to have a dialog.open() method despite the above, it would conflict with the dialog.open property.

にもかかわらず dialog.open() メソッドを用意すると、dialog.open プロパティと衝突してしまう。

Furthermore, a survey of many other UI frameworks contemporary to the original design of the dialog element made it clear that the show/close verb pair was reasonably common.

さらに、dialog 要素のオリジナルの設計と同時代の他の多くの UI フレームワークを調査した結果、show/close 動詞のペアが合理的に一般的であることが明らかになった。

In summary, it turns out that the implications of certain verbs, and how they are used in technology contexts, mean that paired actions such as showing and closing a dialog are not always expressible as antonyms.

まとめると、ある種の動詞の意味合いや技術的な文脈での使われ方によって、 dialog の show と close のような対になる動作は、必ずしも反対語として表現できるとは限らないということがわかるのだ。

— https://html.spec.whatwg.org/multipage/interactive-elements.html#note-dialog-method-names

したがって、もし自前の実装を標準の <dialog> に移行するのであれば、この辺の語彙のすり合わせもやった方がいいだろう。

Demo

動作する DEMO を以下に作成した。

• Dialog Labs | labs.jxck.io
  • https://labs.jxck.io/dialog/

Outro

以上のように、これまで JS/CSS を駆使して実装されていた Dialog の、あらゆる既知の問題を踏まえて、 <dialog> の標準仕様が作られ、 Interop により全てのブラウザが実装し、ほぼほぼ動く状態にあるのだ。

現状 Modal / Dialog 相当を自前やライブラリを用いて実装しているのであれば、基本的には全て <dialog> に置き換えるべきだと言って良い。

次回はもう少し実際のコードで、 <dialog> の使い方および、 Modal / non-Modal の使い分けを解説していく。