-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Add light dismiss functionality to <dialog>
#9373
Comments
I think this is what I'd expect to happen anyway, so that's good. |
Can you expand on this? Intuitively, there's definitely a concept of nesting, e.g. a dialog opened because of an action taken inside another open dialog. I guess popover's notion of nesting is different than this, and that's how you're using the term "nesting"?
I agree this result does seem reasonable. |
Supporting light dismiss for |
Sure. Dialogs can certainly be "stacked" like this, but different from Popover, there's no concept of "nested" popovers. The difference is mainly that Popover has complicated rules about how they're related. In the case of dialog, one dialog can open another dialog, but we don't have logic to connect them to each other. But I think that's ok: dialogs usually aren't used in a "nested" fashion, and when they are, the second dialog should be considered a standalone modal dialog. So one dialog should be dismissed at a time. Example: dialog 1 is "Do you want to save this file?", and on a "no" click, a second dialog shows "Are you sure??" which might cover dialog 1. Clicking outside should just light dismiss the topmost one, and leave the original modal visible.
I'm guessing that's very non-web-compatible. Since the existing dialog requires an explicit close, I bet there are dialogs that don't want to be light dismissed. A light dismiss dialog might not even be the majority use case for modal dialogs: I could see several types of modal dialog that really want explicit action. Like "Choose A or B" - cancel is not an option. |
agreed. light dismiss for modal dialogs should be an opt in, not a default, |
+100 we need this feature. And combined with #3567 I think this will solve a lot of the issues right now with |
One comment that came up in discussion was that the light dismiss behavior should differ from Popover in one respect: if the user clicks outside the dialog to light-dismiss it, that click should not "fall through" to the element underneath the backdrop. That might come for free depending on how we spec/implement this, and how it interacts with |
See openui/open-ui#834 for a quick summary of the TPAC discussion just now, and a new question to discuss the name of the attribute. |
Apologies if this is mentioned in the TPAC discussion or elsewhere that I've missed but I was under the impression the new proposed |
This is automatic for all "close requests", either popup or dialog or In today's TPAC discussion, we called the Esc key behavior "heavy dismiss" (which all dialogs have), to contrast it with the clicking-outside behavior "light dismiss" (which only Note that the HTML spec that got merged is a bit confused about this. https://html.spec.whatwg.org/#popover-light-dismiss lists the Esc key behavior under "canceling popovers"; that triggers "hide popover", not "light dismiss open popovers", which is correct. But the Note says that Esc is a subset of light dismiss, and the "canceling popovers" behavior is under the "Popover light dismiss" heading, so the non-normative aspects are confusing. I will add a fix to that to #9462, to make it clear that they are separate. |
Ah yeah that makes sense. I guess in that case my question should be. Should that behaviour be matched by this lightdismiss definition. If you have multiple dialogs opened without user activation should their light dismiss group such that when the ::backdrop is clicked they all close? It might be odd if escape or back swipe closes them all but you have to manually click out of all of them? |
Made a demo page with a "polyfill" https://demo.lukewarlow.dev/lightdismiss/ |
In the poll, many web developers are suggesting enumerated variants like At first I thought this was not a good idea, because we wanted dialogs to have a baseline close trigger of a close request. So the idea was just to add something that says "also give me close-when-clicking-on-backdrop". For which a boolean attribute name was most helpful. However, in https://bugs.chromium.org/p/chromium/issues/detail?id=1504283 I found out that there are developers using So now I think a model something like the following might work?
I'm not 100% satisfied with this API design, because (Regarding naming: as stated before, I think the name needs to include |
I would want to avoid click in the name because it ties it to a specific input type. I also would want to avoid closeon because it's too similar to onclose. How about closes=""? Then can do closes="closerequest backdrop" closetrigger(s) I think is also fine. While the empty list might be confusing I think it's probably fine (compared to any alternativs I can think of)? |
I agree with @lukewarlow on avoiding I think |
closers is quite nice and short. |
I think an explicit
I will say I'd estimate the order of popularity of these would be:
Having the most desirable be the most boilerplate is not the best. |
Agree re |
I'm not sure about
same with this:
Generally, as I mentioned here, I really don't want to start adding other ways to close the dialog. We spent considerable time ruling out "dismiss-on-scroll" or "dismiss-on-blur", so I'd hope we don't add those as values. They will be easy footguns for most people. For the same avoidance-of-footguns reason, I don't see any use case for a dialog that closes when you click/tap outside it, but does not close when you hit ESC. So there really are just three values/cases, right?
How about:
|
Has |
Interesting point. I agree backdrop is technically not correct in this way. I still think it might be a reasonable way for developers to think about it, because in the default case clicking outside = clicking the backdrop. But if you think it's too misleading, let's go with
This is a good point, and is probably right. However I've already been surprised once by learning that developers sometimes want dialogs that don't respond to close requests. So if anyone disagrees, or can find a dialog of this sort in the web or native platforms, that'd be very helpful info!
LGTM. (And avoids us having to choose between The following possible tweaks come to mind, but I think I prefer your proposal as-is. I just want to write them down in case others have strong feelings.
|
Am I correct in thinking that escape doesn't actually close a non-modal (non-popover) dialog currently. Is that gonna impact on the serialising of the default? |
Right, I agree with this comment. I think this type of behavior is very API-specific, and the target is very specifically dialogs. Popover already has this behavior in a different form, and I haven't heard any requests for this type of feature on other elements/APIs. So I'd love to scope this to dialogs if possible. |
While I agree this shouldn't apply to popover, I wonder about whether it could apply to future high-level elements built on popover. If anyone has a list of those, doing some analysis would be helpful. E.g.: toast? Not sure what their default closedby would be, or whether it'd be reasonable to allow all three options... But even if we wanted to allow only 2 options, that would work fine with this design. |
The two concrete high level elements (obviously modulo name bikeshedding) I've heard discussed are:
In my head at least, both use the Popover API under the covers, and have an implicit |
This I think is key, if we have a specific element built on top of popover and it makes sense to allow two different variants different enough, then they probably should be two separate elements. Of course the same argument could be made for Dialog so maybe I'm wrong. But dialog is closer to popover than some |
Not sure how far along this is, but what if individual attributes was used, rather than bikeshedding them into a single string? <!-- Dialogs are escapable by default, so disable if needed, much like novalidate on forms -->
<!-- if `backdropclose` is present, dialog will call .close() on backdrop click -->
<dialog noescapeclose backdropclose> Alternatively, as modals can ONLY be opened by Javascript dialog.showModal({
closers: { // HTMLDialogCloser?
escape: true, // true is the default
backdrop: true // false is default
}
}) Another option could be to create a dedicated
The event should be preventable, so that would make this possible: <dialog onclose="event.escaped && event.preventDefault()"> This isn't as pretty, but as modals need js and close behaviour is subjective - it might be easier to use if it could be seen what caused the default behaviour, and then to be able to prevent it if needed. |
Modals will soon ™️ be able to be open and closed declaratively fwiw. See One thing to also consider is that non-modal non-popover dialogs have no automatic close by default so using 'nocloserequest' isn't necessarily a good API design. That's not to say separate attributes aren't possible we would just need to think on how they work given the different states. |
While I'm glad that this functionality is being added to the platform, I have concerns around the current design. If we're modeling the behavior of tomorrow's
Since Further, I think there definitely needs to be more customizability. If you think about how custom JavaScript-based dialogs/popovers are implemented today, authors have almost full control over which events will close the dialog/popover. If we want to satisfy all their advanced use cases, the standard From an API perspective, the <dialog closedby="closerequest backdropclick focusout"> In this hypothetical example, I'm listing out three event types, one of which (
I don't particularly care about the exact API, but hopefully this example illustrates how we can empowers authors, while still complementing the more convenient |
Just to provide some quick clarifications (not responding to the core of the comment)
That's not the case it would follow how close watchers (and dialog/popover) work in supporting browsers. E.g. android back gesture or accesibility commands would also close it.
This is already what the html spec says (as much as platform specific behaviours can be specced), for modal dialogs and popovers, and also as mentioned above how closedby would work. |
Thanks for commenting @mayank99 - it's important to get different perspectives captured here!
I just want to pick out this part because I think it's important. Given all the customisability JavaScript dialogs/popovers have, I only really see two distinct behaviours from a huge volume of dialogs; those that work with or without a click-backdrop-to-dismiss behaviour or those that don't. I don't see many (or any) where there are significant other differences such as close-on-scroll or close by another keypress or some such. Could you provide some concrete examples of a dialog or popover being closed during focusout or when scrolled away please? I imagine there won't be any for dialog as this only effects modal dialogs and so focus is trapped - it cannot leave the dialog. |
@keithamus Sure, here are two examples, both really concerned with
Since 1 is so common and is directly tied to WCAG SC 2.4.11, I would expect the platform to help with it. I was looking at openui/open-ui#1047 and it definitely sounds like it's not a good default because Now, I know this thread is specifically about |
As I'm working to spec and implement a prototype of this behavior, an interesting case arose:
In this case, the developer wants the dialog to "light dismiss", but the definition of "clicking outside" becomes interesting, much in the same way that nested popover are interesting. My assumption would be that clicking on the popover, even if that popover is located outside the bounds of the dialog, does not light dismiss the dialog (or the popover). An example use case would be a modal dialog that contains a Feedback appreciated. Assuming the consensus is that I'm right about the desired behavior, then I'll work on integrating dialogs into the popover stack in some way, so that this behavior works. Suggestions for that are also appreciated, since it feels a bit tricky. Another related question:
At this point, there are three light-dismissible modal dialogs open. If I click on |
What's the use case for disabling pressing |
Some folks want to require an action within the dialog, without a "soft" way to exit back out. See https://issues.chromium.org/issues/40944802 for one such request, related to the connection between dialog and CloseWatcher.
Yep, that's still the proposal. The spec PR (#10737) has all the details. |
I've updated the spec PR (#10737) with these behaviors, which seemed natural enough:
It became really tangled to support "nesting" popovers this way inside dialogs, so I just went with standard DOM nesting, which is roughly how dialogs work today anyway. E.g. the
Here, I didn't support the concept of "nesting". That's really a popover thing, and it felt weird to try to impose it back on dialogs. In addition, there are many fewer use cases (perhaps no "good" use cases?) for having multiple modal dialogs open at the same time. Anyway, in the above case, the current PR closes d1 and d2 when d3 is clicked. |
I'm basically with @mayank99 on this one. Overall, I think more granular behavioral controls are needed. |
This is relatively common in my experience, e.g. a modal save dialog and then an error message dialog if you use invalid characters in your filename.
This seems a bit unfortunate to me. My expectation would be that light dismiss behaves the same as a close request, and only closes the topmost dialog---at least, in the subset of dialogs that you clicked "outside of". So in your example where all three dialogs are overlapping:
Whereas in this example: https://jsbin.com/vicuquceji/edit?html,output
Has OpenUI or anyone else done an investigation of dialog light dismiss? I'd have expected this to have come up, e.g. looking at what other design systems do. |
@domenic very good points. And thanks for the example use case. I've opened openui/open-ui#1128 to give this more discussion. Upon putting that issue together, I think I'm coming around to your view, that it would be better to leave the non-topmost dialogs open. But let's discuss. Hopefully you can attend the meeting in two weeks to discuss live. |
Per the discussions at: - openui/open-ui#1128 - whatwg/html#9373 (comment) both developer and editor feedback is that the prior behavior was a bit odd. In the case where there are "nested" dialogs, the desired behavior is for light dismiss clicks to just pop the topmost dialog off the stack, rather than trying to close all non-clicked dialogs. This CL implements that behavior and updates the test. After implementing this behavior and playing with it a bit, I agree with the feedback - this feels more like what users would expect. Once this lands and I get a bit of feedback, I'll incorporate this into the spec PR. Bug: 376516550 Change-Id: I4b5cfb7dd4a27fc304e52759d882b47394e55524 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6068807 Commit-Queue: David Baron <dbaron@chromium.org> Auto-Submit: Mason Freed <masonf@chromium.org> Reviewed-by: David Baron <dbaron@chromium.org> Cr-Commit-Position: refs/heads/main@{#1391794}
Per the discussions at: - openui/open-ui#1128 - whatwg/html#9373 (comment) both developer and editor feedback is that the prior behavior was a bit odd. In the case where there are "nested" dialogs, the desired behavior is for light dismiss clicks to just pop the topmost dialog off the stack, rather than trying to close all non-clicked dialogs. This CL implements that behavior and updates the test. After implementing this behavior and playing with it a bit, I agree with the feedback - this feels more like what users would expect. Once this lands and I get a bit of feedback, I'll incorporate this into the spec PR. Bug: 376516550 Change-Id: I4b5cfb7dd4a27fc304e52759d882b47394e55524 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6068807 Commit-Queue: David Baron <dbaron@chromium.org> Auto-Submit: Mason Freed <masonf@chromium.org> Reviewed-by: David Baron <dbaron@chromium.org> Cr-Commit-Position: refs/heads/main@{#1391794}
Per the discussions at: - openui/open-ui#1128 - whatwg/html#9373 (comment) both developer and editor feedback is that the prior behavior was a bit odd. In the case where there are "nested" dialogs, the desired behavior is for light dismiss clicks to just pop the topmost dialog off the stack, rather than trying to close all non-clicked dialogs. This CL implements that behavior and updates the test. After implementing this behavior and playing with it a bit, I agree with the feedback - this feels more like what users would expect. Once this lands and I get a bit of feedback, I'll incorporate this into the spec PR. Bug: 376516550 Change-Id: I4b5cfb7dd4a27fc304e52759d882b47394e55524 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6068807 Commit-Queue: David Baron <dbaron@chromium.org> Auto-Submit: Mason Freed <masonf@chromium.org> Reviewed-by: David Baron <dbaron@chromium.org> Cr-Commit-Position: refs/heads/main@{#1391794}
…close one at a time, a=testonly Automatic update from web-platform-tests Update dialog closedby behavior to only close one at a time Per the discussions at: - openui/open-ui#1128 - whatwg/html#9373 (comment) both developer and editor feedback is that the prior behavior was a bit odd. In the case where there are "nested" dialogs, the desired behavior is for light dismiss clicks to just pop the topmost dialog off the stack, rather than trying to close all non-clicked dialogs. This CL implements that behavior and updates the test. After implementing this behavior and playing with it a bit, I agree with the feedback - this feels more like what users would expect. Once this lands and I get a bit of feedback, I'll incorporate this into the spec PR. Bug: 376516550 Change-Id: I4b5cfb7dd4a27fc304e52759d882b47394e55524 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6068807 Commit-Queue: David Baron <dbaron@chromium.org> Auto-Submit: Mason Freed <masonf@chromium.org> Reviewed-by: David Baron <dbaron@chromium.org> Cr-Commit-Position: refs/heads/main@{#1391794} -- wpt-commits: e96c4c3d5c6510202598f558ea520b80f9507b31 wpt-pr: 49528
One of the nice features of the Popover API is its light dismiss behavior. In several of the demos of Popover that I've seen, developers are doing something like this:
Using
<dialog>
with a popover attribute is perfectly fine semantically here, since the content represents a dialog. However, this pattern is being used almost entirely because of the features provided by the Popover API which are missing from the<dialog>
element itself. Note the usage of::backdrop
to obscure the backdrop entirely. That indicates that this really is meant to be a modal dialog, because the intent is to focus attention only on the dialog and keep the user from "seeing" the rest of the page. However, popovers aren't modal and as such they don'tinert
the rest of the page. So in the above example, keyboard users are free to tab-navigate to other content they can't see. Mouse users are free to click "through" the opaque background onto unseen elements. Generally, it'd be better if this was a plain old modal<dialog>
and not a popover.To get around this usage pattern, let's bring the missing functionality to
<dialog>
. #3567 discusses one of those behaviors, namely declarative invocation of<dialog>
. In this issue, I'd like to propose a mechanism to add light dismiss to<dialog>
s.Proposal (subject to bikeshedding):
With the
lightdismiss
attribute present, clicking outside the dialog, or hitting ESC (or other close signals) will have the same affect as callingdialog.close()
.Note one nuance, which is different from popover: since there's no concept of "nested" dialogs, if more than one dialog is open at a time, only the topmost (most recently opened) dialog will be closed on each light dismiss action. So if three dialogs are open and the user clicks outside all three of them, only the topmost dialog will close. Generally, nested dialogs is an anti-pattern, but even so, this feels the most natural to me anyway.
The text was updated successfully, but these errors were encountered: