[HN Gopher] What Is Popover=Hint?
___________________________________________________________________
What Is Popover=Hint?
Author : speckx
Score : 47 points
Date : 2025-08-04 12:55 UTC (4 days ago)
(HTM) web link (una.im)
(TXT) w3m dump (una.im)
| vintagedave wrote:
| 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.
| cwillu wrote:
| Scroll down to the last example: https://una.im/popover-
| hint/#lets-see-it-in-action
| mirkodrummer wrote:
| 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
| webstrand wrote:
| 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.
| pentium166 wrote:
| 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.
| ronbenton wrote:
| >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
| charrondev wrote:
| 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.
| webstrand wrote:
| 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)
| cosmic_cheese wrote:
| 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.
| pentium166 wrote:
| 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.
| zahlman wrote:
| 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)...
| webstrand wrote:
| I see rgb(35, 48, 43) background on the code spans. Do you have
| some plugin installed that's messing it up?
___________________________________________________________________
(page generated 2025-08-08 23:01 UTC)