-
Notifications
You must be signed in to change notification settings - Fork 192
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What should "nested" dialog light dismiss look like? #1128
Comments
Yes, it's important that clicking on inner should not close any lower dialogs. It should leave
Right. Only one dialog should close at a time. Closing many may be an unpredictable behaviour, and would sow distrust for the user as to what they can anticipate.
We have some nested dialogs where In the above image, there is actually a more complex case: the |
This is very helpful - thanks.
Thanks also for this use case. I believe this should be easy to implement, within the currently proposed behavior (whatwg/html#9373), by adding a listener for the outer dialog's |
Yes absolutely. No concerns on that particular behaviour. |
I have a spec PR open to add dialog "light dismiss" capabilities, via a new
closedby
attribute, here: whatwg/html#9373. One question came up (see discussion starting roughly here) about what the behavior should be for "nested" dialogs. I keep putting quotes around "nested" because dialogs don't have any current notion of being "nested", in the same way that popovers explicitly do (see the bigNote
here: https://html.spec.whatwg.org/#topmost-popover-ancestor). So any behavior we add here is essentially inventing some concept of nested dialogs.So the question is, what are typical expectations for users or developers when multiple modal dialogs are open, and the user clicks outside one of them. I'd like to side-step the question of modeless dialogs, at least for now, since I consider modals the more pressing, and common, use case.
Here's a demo to work with (borrowed and tweaked from @domenic):
Some things to note:
showModal
calls.::backdrop
covering the area outside the dialog.inner
is actually a click oninner
's::backdrop
. It is impossible to click onouter
or its::backdrop
.There are three positions that a user might try to click (labeled in red in the demo above):
inner
's border box.outer
's border box.Note, again, that #2 and #3 are both actually clicks on the backdrop of
inner
.In terms of potential outcomes, for each click position:
inner
should always leaveinner
visible. It could either closeouter
or leave it open. It seems like it makes the most sense to leaveouter
open, at least to a user for this use case.inner
, soinner
should clearly close. And because it's an attempted click onouter
, it seems likeouter
should stay open.inner
should close, since it is topmost. The question is whether the user expects this click to just closeinner
and leaveouter
open (i.e. just pop one dialog off the stack), or whether both should close. My assumption is that in all design systems today that implement "light dismiss dialogs",outer
stays open, just due to implementation. But I'd love confirmation.The point of this issue is a) to make sure I haven't missed something, and b) to check expectations for behavior. I'd love to discuss, so Agenda+.
The text was updated successfully, but these errors were encountered: