The utility of the `popover=hint` feature

[mfreed7]

I'm opening this issue to discuss the utility of popover=hint, generally. Note, importantly, that this is separate from the Interest Invokers feature, and the related issue about how to handle touch-activation of hovercards. The popover=hint feature is an orthogonal part of creating "subordinate" popovers, which don't interfere with existing popover=auto's that are open on the page. The explainer is here, and in particular, this section describes the exact behavior that popover=hint provides.

There is a formal objection from WebKit/Apple on the spec PR for this feature (whatwg/html#9778 (comment)). While that comment comes with no details, a related comment on the WebKit standards thread (WebKit/standards-positions#305 (comment)) indicates that perhaps the objection is because they feel that popover=hint is "tied" to solving Interest Invokers, and they don't want "encourage" tooltips and hovercards in the meantime.

I'd like to use this issue to do two things:

1. Discuss whether there is utility in a popover=hint feature, even if there isn't (yet) an interest-invokers feature.
2. Discuss the general utility, prevalence, and support for hovercards, tooltips, and other UI patterns that might use popover=hint.

[keithamus]

It seems like hint would also be useful for ephemeral floating UI like toasts or notifications. The ability to open a popover that doesn't close other auto popovers, but still has the light dismiss capabilities of auto-style popovers. Having said that toasts/notifications are a little contentious a11y wise.

[scottaohara]

similar light dismiss, but not exactly the same, i'd think?

[css-meeting-bot]

The Open UI Community Group just discussed The utility of the `popover=hint` feature.

The full IRC log of that discussion

<hdv> keithamus: popover hint is a new value that will allow you to place a popover, like auto, but it won't close other autos
<hdv> keithamus: so it's almost like a new layer or stack
<hdv> keithamus: there can only be one hint open at a time
<hdv> keithamus: the predominant use case is to have tooltip style popovers
<hdv> keithamus: like when you hover over a link or interactive control, a tooltip will open up
<hdv> keithamus: toasts and notifications also don't want to close other popovers
<brecht_dr> q+
<hdv> keithamus: so the discussion is … what's the utility of hint as a separate part of the platform?
<brecht_dr> q-
<hdv> gregwhitworth: I'll clear this issue
<hdv> gregwhitworth: as we're waiting for responses

[css-meeting-bot]

The Open UI Community Group just discussed The utility of the `popover=hint` feature.

The full IRC log of that discussion

<brecht_dr7> q+
<hdv> masonf: my feeling is popover=hint is going to be useful together with other things and on its own
<JakeA> q+
<hdv> masonf: is popover=hint useful on itsown even if you have to do the JS yourself
<hdv> s/yourself/yourself?
<gregwhitworth> ack brecht_dr7
<gregwhitworth> ack brecht_dr
<hdv> brecht_dr7: I think it's fairly useful even without interest, I see examplewhere you could have a popover inside of a popover… could have, like, a toggletip situation, like a question mark icon
<sarah> q+
<hdv> brecht_dr7: those are things that could work… even if it's not on hover or focus style… popover=hint could still be useful to force close other hints
<gregwhitworth> ack JakeA
<hdv> JakeA: if I'm understanding the issue correctly… with popover=hint the popovers are part of a different group than others… would it make sense to have popovergroups so that you could group your poopvers in general?
<keithamus> q+
<hdv> masonf: it's already a bit confusing to explain the 'two stacks of popovers'
<scott> q+
<hdv> masonf: hints are subordinate to the others
<keithamus> q-
<hdv> masonf: if you're defining n groups, it will be a bit funny
<hdv> masonf: think zindex
<gregwhitworth> ack sarah
<hdv> sarah: the library I work on, we have codes to do essentially this
<hdv> sarah: the code to handle 'only one at a time top layer tooltips': as good as we can do, but you can throw in iframes etc… it gets really difficult … so to have the browser solve the 'one at a time' kind of thing would be very useful to us
<hdv> sarah: would help us get rid of a bunch of hacky code
<hdv> masonf: it's not straightforward to put this into spec and into code, so would echo that
<JakeA> I need to switch to another meeting. Thank you all!
<gregwhitworth> ack scott
<hdv> s/that/sarah's points
<hdv> scott: wanted to echo support for popover=hint… for the tooltip case specifically
<hdv> scott: I would probably rather have a tooltip element rather than this… because the other use cases seem more like popover=manual for me
<hdv> keithamus: but you would lose out on light dismiss which is a pain to reimplement
<hdv> scott: I'm thinking about things like toasts
<hdv> keithamus: but you probably want a close watcher… which is easy ish to do but not as easy as getting it for me
<hdv> s/me/free
<hdv> scott: either way I want to support popover=hint, agree with sarah, doing this yourself is difficult
<hdv> keithamus: yes, agreed it is great as a separate thing, popover=manual alone is not enough
<hdv> RRSAgent, make minutes please
<hdv> Zakim, make minutes please
<Zakim> I don't understand 'make minutes', hdv
<RRSAgent> I have made the request to generate https://www.w3.org/2024/10/24-openui-minutes.html hdv

[sorvell]

I think it's not unusual to need to present tooltips for a lot of elements where it might be desirable to create the ephemeral DOM on demand. Is supporting that robustly a potential goal for this feature?

[css-meeting-bot]

The Open UI Community Group just discussed The utility of the `popover=hint` feature, and agreed to the following:

• RESOLVED: popover=hint is a useful and desirable feature on its own, separate from interesttarget.

The full IRC log of that discussion

<nmn> masonf: this issue of popover + hints has been talked about once. I left it on the agenda because, the next issue is hovercards + touch. So, to make it clear there are two issues in my head. 1 is called popover + hint, the other is hover activation of those popovers
<keithamus> q+
<masonf> q+ keith
<masonf> ack keith
<masonf> ack keith
<nmn> masonf: the question for today is if the second feature never happens, is the first feature still useful?
<nmn> keith: yes, it's very useful.
<sarah> q?
<sorvell> q+
<sarah> q+
<nmn> keith: we implement custom tooltip on github.com. we popover=manual because we don't want other auto popups to dismiss. it's not always ppossible to nest them. If we don't get popover=hint, we'll continue using popover=manual. this feature reduces code
<masonf> ack sorvell
<keithamus> q+
<nmn> sorvell: I completely agree with keith, my only question is, is there any value having these separate layers of stacks? yes. But i'm not sure it should be exactly two. Maybe I want to have a stack for toasts, which is separate from tooltips and others.
<nmn> masonf: are you advocating for three?
<nmn> sorvell: that's my only concern, otherwise it's valuable.
<nmn> masonf: there's two because we found exactly two use-cases. I have yet to see anything else.
<nmn> masonf: the example is select, that's a primary popover
<masonf> ack sarah
<nmn> sarah: I actually do like exactly two, because that's what we found, we have a usecase for exactly two. the one is selects etc, the other is tooltips. I don't think we've ever had more than that.
<nmn> sarah: I too think there should be exactly two.
<nmn> sarah: it would get rid of a lot of complexity.
<masonf> ack keith
<scott> +1 to it being a manual for toast
<nmn> keith: I'm here to advocate for exactly two as well. I understand the Toast use-case, but either it goes into the hint stack or the manual.
<nmn> keith: I would argue the value trade-off is worse, specially for "n" stacks.
<nmn> keith: Maybe where that would be a case is if you want to show all of your tooltips at once.
<masonf> q+nmn
<keithamus> scribe+
<nmn> keith: maybe you have a game and you want to see them all at once
<keithamus> nmn: I wanted to chime in on the toast case; that has been a challenge a11y wise for Facebook. We're still discussing. I don't know if toasts is the correct term - the pattern on a11y websites show low risk info that you want to announce. Like aria-live
<keithamus> nmn: in practice they're used for notifications, and may even have buttons like "okay"/"got it". Similar to confirm dialog but non-modal
<keithamus> nmn: Like "hey are you okay with this?". And it persists until you click it.
<masonf> q+
<keithamus> nmn: toasts are on a timer though, so the pattern is different - but that has a11y issues, you need to increase the timeout, delay others, it's all a big mess honestly.
<masonf> ack nmn
<keithamus> nmn: the only solution for the UI problem is to show a list of toasts where they may not all be visible at once, but you can see an amount, and scroll the rest. Some toasts can be dismissed automatically while others stick around.
<keithamus> nmn: not sure if it's relevant but wanted to bring it up as a use-case.
<nmn> masonf: i wanted to chime in on a couple of things, toasts shouldn't be popover=auto or popover=hint, right?
<nmn> nmn: yeah I think so.
<nmn> masonf: thank you for the support for n=2 for the number of stacks. I don't think anything here precludes a third stack if a use-case arises.
<nmn> masonf: if a new usecase arises we can add a new popover=something stack
<nmn> masonf: and the last thing I wanted to say: Generally I heard support for popover=hint even without hover triggerring. Because there is a question if this feature is tied to interest target.
<sorvell> q+
<masonf> ack mason
<nmn> masonf: I'd like to not be blocked by having to ship interesttarget if possible. Is there a reason this is a bad idea?
<masonf> ack sorvell
<nmn> sorvell: no, I don't see any reason to object. I think it's useful and valuable. But I have a point of clarification, the objection is not challenging the usefulness of the feature, but the usefulness is offset by the fact that we don't have a good pattern for showing and hiding it. I think that was a concern.
<nmn> masonf: yes, the concern I heard was that "we don't think hovercards and tooltips are good for users", and my argument is that we already have them and we should support them.
<sarah> q+
<masonf> ack sarah
<nmn> sarah: I'm probably one of the people that's most against hovercards. I still think it's a good feature for the web. It's such an entreched UI, we should be able to support them
<nmn> sarah: anything like touch won't get it. You can get a little bit of a preview, like on Github, but then designers over-rely on them. And then screenreader users and others don't have access.
<sorvell> q+
<nmn> masonf: you say you want to support popover=hint, but you also don't want to use it until the second one is fixed so are you saying we should wait?
<nmn> sorvell: The one concern that I have is that one of the patterns I've seen used often is that there are ton of tooltips, my extra tooltip being in the DOM is heavy. I hope the feature supports creating this on-demand is possible.
<keithamus> q+
<nmn> masonf: If you're talking about dynamic, you're already using JS. Wouldn't you use a single tooltip and open it as needed.
<nmn> sorvell: if there hovercard that's a browser trusted thing I need to be careful.
<masonf> ack sorvell
<masonf> ack keith
<nmn> masonf: there's no browser trusted thing. You should be able to use JS to create the popover on demand.
<nmn> keith: the hint feature, as I understand it, won't actually open the popover. You'll have to call .showPopover(). It will close for you, it has light-dismiss. But it's your responsibility to open the popover.
<nmn> keith: You'll have to use the mouse event handler etc, and call showPopover(). But the popover=hint is this subtle difference.
<nmn> keith: I think that's where the dividing line between these two features is. So the other question is how we solve the other problem by having something like "interest", by using the equivalent of hover on other platforms.
<nmn> keith: I think it's solvable because,... uh, maybe it's not in the DOM.
<masonf> Proposed resolution: popover=hint is a useful and desirable feature on its own, separate from interesttarget.
<masonf> RESOLVED: popover=hint is a useful and desirable feature on its own, separate from interesttarget.
<nmn> masonf: proposed resolution: popover=hint is a useful feature without interest-target. Any objections?