-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
closedby attribute doesn't work when dialog uses the popover API #11105
Comments
Can you say more about why? From a user's point of view, I think there's something of an expectation that a |
A UX debate can be had for either approach, but I think it's best to let developers/designers decide based on the specific context. For a non-modal dialog, the user may be clicking outside of the dialog because they want to interact with the page, not because they want to close the dialog (whereas pressing the escape key is explicitly an action to close a dialog). The whole point of a non-modal dialog is that the page remains interactive, allowing users to continue their activity with the option to interact with the modal when they choose to.
I think there's a middle ground where a dialog is somewhat important/useful but does not require immediate attention, so the disruption of a modal dialog would be best avoided. Just because a dialog is non-modal doesn't mean it is frivolous. A vital error notification might be implemented as a non-modal dialog, for example. Important notifications might be accidentally dismissed before the user has a chance to read them, because the user was busy interacting with the page, which will instantly close the notification. (see this example from the Nord design system). What if the user wants to interact with the dialog, but is in the middle of another activity they want to complete first? A menu or a tooltip can be easily reopened by the user, so light dismiss functionality makes sense. The same is not always true of dialogs, which is why I feel that light-dismiss makes it too easy to close a dialog. There may be no way for the user to reopen that dialog again, so I'd want the close action to be purposeful rather than an accidental unknowing byproduct of clicking the page. Modeless dialogs are often small and confined to the bottom corner of the screen so they aren't disruptive or distracting, so there's no great benefit to dismissing them so effortlessly. For another use-case, see the Gmail example discussed by NN Group:
Some example non-modal dialogs in the wild that do not use light-dismiss: IBM Carbon design system:
Fluent UI docs:
ServiceNow docs:
Plenty of cookie consents are non-modal and allow interaction with the page. See the Google example below or cookie dialog on the Smashing Mag site. Non-modal dialogs that use the |
I completely agree that we need One use-case: I've worked on some very complex interfaces, where multiple non-modal dialogs may be open at the same time. These dialogs stay in top layer, can be dragged around, and allow moving focus between each other. It would be nice to have a declarative way of closing these dialogs using Esc. |
What is the issue with the HTML Standard?
Non-modal dialogs should be able to make use of the
closedby
attribute.A dialog using the
.show()
method oropen
attribute does not make use of the top layer, which can lead to issues with z-index. For that reason, combining the dialog element with the popover attribute is probably a better approach for non-modal dialogs (There's even an open issue with many thumbs ups for deprecatingdialog.show()
. There is no invoker command to open a non-modal dialog precisely because combiningshow-popover
with<dialog>
is considered a better approach for this use case).For a non-modal dialog, I do not want light dismiss when the user clicks the page, so I would use
popover="manual"
. I do want the escape key to close the dialog, as this is an expected behaviour for dialogs. Because I have opened the dialog via.showPopover()
rather thanshow()
orshowModal()
, closing via the escape key is not default behaviour. Currently I would need to manually add this behaviour with JavaScript via a CloseWatcher. This is fairly trivial but I do think the current behaviour will trip people up.The
closedby
attribute is a way for developers to state via HTML how a dialog can be closed. The way it is currently specced, it does not work when the dialog has been shown via.showPopover()
. This is unfortunate. Not only is it a simpler approach than using script, it represents a consistent way to solve this issue. Seeing asclosedby
is a very explicit way to specify what behaviour is wanted, it should override the popover behaviour.The
closedby
attribute is for dialogs, and regardless of how it gets shown, if an element is a dialog, the developer expectation will be that they can useclosedby
. The following should be specced to work:The text was updated successfully, but these errors were encountered: