I've been trying to use HTML's native popover and dialog recently. The promise of not having to write/import focus traps, better integration with standard platform "cancel" UX, the top layer concept, etc made them sound great, but in reality it's been kind of painful.
Stacking order when you have multiple modal dialogs and popovers in the top layer is based on most recently revealed element, so that toast that just opened is now hidden under a dialog. Anchoring is currently only supported in Chrome, so popover tooltips show up in the corner. Firefox supports transition animations when opening a dialog but not closing it. The web platform feature needed to tie the mobile back button to closing a dialog isn't actually implemented yet. Frameworks that patch the DOM might clobber modal dialog state because it's a function of both the "open" attribute and the result of showModal().
Some of these will improve but I think the display order problem is here for the long haul.
>Stacking order when you have multiple modal dialogs and popovers in the top layer is based on most recently revealed element, so that toast that just opened is now hidden under a dialog.
Whenever I have to fight something like this it always makes me question the goodness of the pattern to begin with. Stacking multiple modals/popovers/tooltips can’t be a great UX (or accessibility) pattern, can it? I find at least half the time that I’m fighting the browsers it’s because I’m trying to do something suboptimal
I agree that stacking multiple modal dialogs should generally be avoided, and if whatever you're doing is complex enough you should consider whether it needs to be in a dialog at all.
What I'm talking about is if I'm using popover to alert the user about something, let's say another user updated the page they were viewing, and they clicked into a confirmation dialog fractions of a second after the alert arrived, the alert is now behind the dialog and attempting to click on it either does nothing or closes the dialog, depending on how I've configured the dialog.
As the application developer, I'm responsible for deciding how the modes in my multi-modal application behave, and I want top-level alerts like this example to be interactable and in front of confirmation dialogs in all modes, regardless of which one opened first. With the current top layer behaviour, that is not really achievable without doing something like reparenting open alert popovers into the most recently opened dialog, and that's ALSO not properly functional (element state gets reset) until Element.moveBefore() is generally available.
It’s a pattern that I’ve seen called dialog tunneling, and I think the most prominent example of it is Windows 9x up through 7. Web apps are pretty bad about it too though, more often than not because navigation can’t be made sensible when there’s a new feature that needs to be shoved in front of users every few weeks/months, so stuff ends up getting buried in dialogs N deep to make room.
I have an ImageViewer component, which is sometimes displayed in a modal dialog for confirming operations on that image, like delete, move, deduplicate, etc.
The ImageViewer has a context menu popover that needs to appear above the modal that contains it. Using the Popover API lets me be sure that there'll be no z-fighting, the popover won't be clipped by its parent element, and that the popover will dismiss correctly when the user wants it gone. It's pretty great, and I don't think it harms accessibility any more than _having_ a context menu in the first place harms it. And the UX is fine.
(Aside from some hellish work making it so that `oncontextmenu` can actually open a popover. According to the spec, right button mouseup triggers light dismiss, closing the context menu as soon as it opens)
Stacking modals is no good for sure, but just because a form is part of a modal doesn’t mean it should never be able to use a tooltip, dropdown, or popover.
This is confusing. In the screen recording, I see two popovers, _both_ of which appear when clicking.
Yet I would view a hint as one that appears simply on hover: a tooltip.
The article jumps ahead "But wait, didn’t clicking on the hint popover close the auto one? ... Because you’re inducing an action (click), it activates the light-dismiss of the auto popover. This is almost certainly not what you want when you’re creating a hint popover." but completely omits what a hint is supposed to be in the first place and whether this actually is a hint. As far as I can tell, this hint type of popover is not actually behaving like a desktop-style tooltip hint.
I feel like a page trying to teach something about new CSS features should not be showing me code spans (in dark mode) with the colour combination of rgb(236, 210, 197) on rgb(250, 243, 243)...
Yeah, it is. And the website actually uses `prefers-color-scheme` too. It looks like this is a bug.
The website sets `[data-theme="dark"]` via javascript on page-load so that its light/dark toggle button works, and its stylesheets duplicate every style from `prefers-color-scheme` to `[data-theme="dark"]`. The duplication messed up `--astro-code-bg` and copied from the light scheme.
I have whys not whats. Why we waited so much(years!) for such api as a browser built in? Why I feel it overwhelming/not well thought off for such simple use case? I still feel like including a 3rd party library and instantiating a tooltip to be more straight forward, if anything these libraries are built upon years of know how and we don't need to wait for a browser vendor to add a new attribute on his own for a marginal improvement. Marginal improvement one would understand immediately right? No "hint" is a not a simple tooltip. And why the heck we would ever need a table grid to explain a feature that should be simple? I'm so sick of the web platform and its inefficiencies
One big reason is that light-dismiss behavior is built into the browser now, and its way more consistent than what various tooltip libraries provide. In my experience, there's usually some pattern of input/focusing that can make a library-provided tooltip fail to dismiss and become stuck on the screen.
I've been trying to use HTML's native popover and dialog recently. The promise of not having to write/import focus traps, better integration with standard platform "cancel" UX, the top layer concept, etc made them sound great, but in reality it's been kind of painful.
Stacking order when you have multiple modal dialogs and popovers in the top layer is based on most recently revealed element, so that toast that just opened is now hidden under a dialog. Anchoring is currently only supported in Chrome, so popover tooltips show up in the corner. Firefox supports transition animations when opening a dialog but not closing it. The web platform feature needed to tie the mobile back button to closing a dialog isn't actually implemented yet. Frameworks that patch the DOM might clobber modal dialog state because it's a function of both the "open" attribute and the result of showModal().
Some of these will improve but I think the display order problem is here for the long haul.
>Stacking order when you have multiple modal dialogs and popovers in the top layer is based on most recently revealed element, so that toast that just opened is now hidden under a dialog.
Whenever I have to fight something like this it always makes me question the goodness of the pattern to begin with. Stacking multiple modals/popovers/tooltips can’t be a great UX (or accessibility) pattern, can it? I find at least half the time that I’m fighting the browsers it’s because I’m trying to do something suboptimal
I agree that stacking multiple modal dialogs should generally be avoided, and if whatever you're doing is complex enough you should consider whether it needs to be in a dialog at all.
What I'm talking about is if I'm using popover to alert the user about something, let's say another user updated the page they were viewing, and they clicked into a confirmation dialog fractions of a second after the alert arrived, the alert is now behind the dialog and attempting to click on it either does nothing or closes the dialog, depending on how I've configured the dialog.
As the application developer, I'm responsible for deciding how the modes in my multi-modal application behave, and I want top-level alerts like this example to be interactable and in front of confirmation dialogs in all modes, regardless of which one opened first. With the current top layer behaviour, that is not really achievable without doing something like reparenting open alert popovers into the most recently opened dialog, and that's ALSO not properly functional (element state gets reset) until Element.moveBefore() is generally available.
It’s a pattern that I’ve seen called dialog tunneling, and I think the most prominent example of it is Windows 9x up through 7. Web apps are pretty bad about it too though, more often than not because navigation can’t be made sensible when there’s a new feature that needs to be shoved in front of users every few weeks/months, so stuff ends up getting buried in dialogs N deep to make room.
Definitely registers as poor UX in my book.
I have an ImageViewer component, which is sometimes displayed in a modal dialog for confirming operations on that image, like delete, move, deduplicate, etc.
The ImageViewer has a context menu popover that needs to appear above the modal that contains it. Using the Popover API lets me be sure that there'll be no z-fighting, the popover won't be clipped by its parent element, and that the popover will dismiss correctly when the user wants it gone. It's pretty great, and I don't think it harms accessibility any more than _having_ a context menu in the first place harms it. And the UX is fine.
(Aside from some hellish work making it so that `oncontextmenu` can actually open a popover. According to the spec, right button mouseup triggers light dismiss, closing the context menu as soon as it opens)
Stacking modals is no good for sure, but just because a form is part of a modal doesn’t mean it should never be able to use a tooltip, dropdown, or popover.
This is confusing. In the screen recording, I see two popovers, _both_ of which appear when clicking.
Yet I would view a hint as one that appears simply on hover: a tooltip.
The article jumps ahead "But wait, didn’t clicking on the hint popover close the auto one? ... Because you’re inducing an action (click), it activates the light-dismiss of the auto popover. This is almost certainly not what you want when you’re creating a hint popover." but completely omits what a hint is supposed to be in the first place and whether this actually is a hint. As far as I can tell, this hint type of popover is not actually behaving like a desktop-style tooltip hint.
Scroll down to the last example: https://una.im/popover-hint/#lets-see-it-in-action
I feel like a page trying to teach something about new CSS features should not be showing me code spans (in dark mode) with the colour combination of rgb(236, 210, 197) on rgb(250, 243, 243)...
I see rgb(35, 48, 43) background on the code spans. Do you have some plugin installed that's messing it up?
Apparently, JavaScript has to be running in order for that colour selection to work properly. Is that not what `prefers-color-scheme` in CSS is for?
Yeah, it is. And the website actually uses `prefers-color-scheme` too. It looks like this is a bug.
The website sets `[data-theme="dark"]` via javascript on page-load so that its light/dark toggle button works, and its stylesheets duplicate every style from `prefers-color-scheme` to `[data-theme="dark"]`. The duplication messed up `--astro-code-bg` and copied from the light scheme.
I have whys not whats. Why we waited so much(years!) for such api as a browser built in? Why I feel it overwhelming/not well thought off for such simple use case? I still feel like including a 3rd party library and instantiating a tooltip to be more straight forward, if anything these libraries are built upon years of know how and we don't need to wait for a browser vendor to add a new attribute on his own for a marginal improvement. Marginal improvement one would understand immediately right? No "hint" is a not a simple tooltip. And why the heck we would ever need a table grid to explain a feature that should be simple? I'm so sick of the web platform and its inefficiencies
One big reason is that light-dismiss behavior is built into the browser now, and its way more consistent than what various tooltip libraries provide. In my experience, there's usually some pattern of input/focusing that can make a library-provided tooltip fail to dismiss and become stuck on the screen.