popover=hint

[mfreed7]

WebKittens

No response

Title of the spec

popover=hint

URL to the spec

whatwg/html#9778

URL to the spec's repository

https://github.com/whatwg/html

Issue Tracker URL

No response

Explainer URL

https://open-ui.org/components/popover-hint.research.explainer/

TAG Design Review URL

No response

Mozilla standards-positions issue URL

mozilla/standards-positions#965

WebKit Bugzilla URL

https://bugs.webkit.org/show_bug.cgi?id=275048

Radar URL

No response

Description

This is related to, but not blocked/gated by, the invokers proposal.

See also, whatwg/html#9776.

[annevk]

I think it would be good to address the issue we discussed in the last WHATNOT about features participating in the top layer concept all needing to be able to nest. As this would be another such feature and should ideally build on that envisioned infrastructure.

[mfreed7]

I think it would be good to address the issue we discussed in the last WHATNOT about features participating in the top layer concept all needing to be able to nest. As this would be another such feature and should ideally build on that envisioned infrastructure.

Yep, that's a good point. I think that should be roughly orthogonal to this feature, or at least should "just work", but I'll get that prototyped to see what it looks like.

[annevk]

Some other thoughts upon reading more:

• Assuming [css-ui] Standardize tooltip styling and expose as ::tooltip w3c/csswg-drafts#8930 happens, shouldn't this be called "tooltip" as well? It's somewhat surprising how much the explainer talks about "tooltip", only for the feature to be called "hint".
• What happens when auto is nested inside hint? There's also questions here what happens if you trigger a model dialog and such, but maybe that would fall out of fixing the above bug. (Though that would not make them orthogonal.)

[mfreed7]

Some other thoughts upon reading more:

• Assuming [css-ui] Standardize tooltip styling and expose as ::tooltip w3c/csswg-drafts#8930 happens, shouldn't this be called "tooltip" as well? It's somewhat surprising how much the explainer talks about "tooltip", only for the feature to be called "hint".

Yeah, we discussed this at some length in OpenUI, in various places. But the main discussion is located here: openui/open-ui#532. You'll note in my OP I agree with you that the primary use case is "tooltip" (and also in this comment openui/open-ui#532 (comment)). But there was some pushback to using the name of a use case for the value. I'd personally be fine with popover=tooltip. If this is a sticking point, I can re-open that discussion.

• What happens when auto is nested inside hint?

The idea is that auto can't be nested inside hints. The behavior will be that the topmost popover ancestor algorithm will be modified so that it does not detect an auto "inside" a hint as forming an ancestor relationship. In practice this means that opening the auto will cause the hint to close.

There's also questions here what happens if you trigger a model dialog and such, but maybe that would fall out of fixing the above bug. (Though that would not make them orthogonal.)

I'm almost done implementing the modal dialog and fullscreen interactions thing, and I've prototyped it for both auto and the new hint proposed behavior. You'll have to trust me for now, but it seems like it'll fall out fairly naturally.

[annevk]

@mfreed7 I left a comment on the Open UI issue. I can't reopen. I feel pretty strongly naming should be consistent across the web platform. Getting ::tooltip renamed to ::hint with the blessing of the CSS WG seems okay too.

[mfreed7]

@mfreed7 I left a comment on the Open UI issue. I can't reopen. I feel pretty strongly naming should be consistent across the web platform. Getting ::tooltip renamed to ::hint with the blessing of the CSS WG seems okay too.

Thanks. I commented there also and added that issue back to the agenda to talk about again.

[annevk]

Hey @mfreed7, we discussed this a bit again and one question we have is whether this is going to be the final popover attribute value? Or if perhaps this new stack signifies a need for something broader.

[mfreed7]

Hey @mfreed7, we discussed this a bit again and one question we have is whether this is going to be the final popover attribute value? Or if perhaps this new stack signifies a need for something broader.

We (Chromium) don't have any plans to pursue other values. And I also haven't heard any requests for other values/behaviors. The set of three (auto, hint/whatever, manual) seems to cover the breadth of the use cases for popovers.

[mfreed7]

Any further thoughts on this one? There's now an approved spec PR and a prototype implementation that seems to work nicely. We'd love to get multi-implementer support.

[koddsson]

https://bugs.webkit.org/show_bug.cgi?id=275048 here's the bug

[annevk]

Colleagues and I discussed this quite a bit after more closely looking at the primary use case of this feature (as well as interesttarget) and we agree that exposing the kind of information you see in rich tooltips on "desktop" platforms in a simpler manner is a valuable idea. However, we currently don't see a good UX for this across the many platforms that the web has to support. Tooltips as we know them on desktop are notably absent on "mobile" platforms and have been for close to two decades.

For certain element types there are workarounds (e.g., img as seen most famously on xkcd), but those are not generally applicable and also would not work for "rich tooltips" (unless you would be okay with being multiple taps away from something that is a mouse move on desktop, but that is not something we are okay with).

As such we are currently leaning negative on this idea.

[mfreed7]

Thanks for the feedback!

Colleagues and I discussed this quite a bit after more closely looking at the primary use case of this feature (as well as interesttarget) and we agree that exposing the kind of information you see in rich tooltips on "desktop" platforms in a simpler manner is a valuable idea. However, we currently don't see a good UX for this across the many platforms that the web has to support. Tooltips as we know them on desktop are notably absent on "mobile" platforms and have been for close to two decades.

This sounds like you're actually supportive of trying to solve the "tooltips" use case, am I correct? You say that rich tooltips are a valuable idea, and the existing platform support is relatively bad, especially for mobile. Just confirming that your view is positive on the use case, but negative on the particulars. If I'm wrong about that, please help me understand the view.

For certain element types there are workarounds (e.g., img as seen most famously on xkcd), but those are not generally applicable and also would not work for "rich tooltips" (unless you would be okay with being multiple taps away from something that is a mouse move on desktop, but that is not something we are okay with).

I agree that the text-only workarounds (which are typically adding the plain-text title value to the top of the existing long-press context menu) would not be applicable to "rich tooltips" on mobile. We would require either:

1. More innovation on ways to activate rich tooltips via touch, while still retaining the existing context menus and selection behaviors.
2. Be "ok" with requiring multiple taps to access the rich tooltip, and just add an item like "show tooltip" to the top of the long-press context menu.

I'm actually fine with either solution! Solution 1, which currently doesn't exist, is obviously better, once you figure out what it is. In the meantime, solution 2 actually does solve a problem for users today, in that it provides access to otherwise inaccessible content on mobile. The current state of affairs for rich tooltips on the web today is that they're most often completely broken and inaccessible to touch users.

Please help me solve this problem!

[mfreed7]

One additional comment here. This standards position request is about the popover=hint spec PR, and isn't about the interest invokers API. The comments @annevk made above all seem directly related to how a "tooltip" is invoked via touch, and are basically unrelated to the changes being proposed for popover=hint. I'd like to move the entire "tooltip" use case forward, so I'd love to continue discussing those concerns and finding a solution. But is it possible there might be support for this specific proposal for popover=hint?

[annevk]

In our view they are tied. If we don't have a good cross-platform solution for rich tooltips we should not be adding anything that further encourages their use.

[mfreed7]

In our view they are tied. If we don't have a good cross-platform solution for rich tooltips we should not be adding anything that further encourages their use.

Combining this with the comment above, it sounds like you're supportive of tooltips, but don't feel there's a good solution for touch. In that case, please help us design a good solution! The best we have right now is one of these two things:

1. Mandate the exact mechanism for interest-triggering on keyboard and mouse systems, but leave the details to UAs for touchscreens. The spec should mandate that UA's support interest-based triggering regardless of the input modality, but on non-keyboard/mouse, the details are left to the UA.
2. Mandate the exact mechanism for interest-triggering on touchscreens also. I believe the only feasible cross-platform, cross-device solution is to mandate that interest triggering is added as an option in the long-press context menu that exists on all platforms today.
3. (Not really an option I think) Mandate the exact mechanism for interest-triggering on all platforms, e.g. Vision Pro, watch screens, etc.

I'm in favor of #1, because I believe it leaves some flexibility to browser vendors and even hardware manufacturers to innovate on touchscreen mechanics. However, I am willing to live with #2 if that's what it takes to help move tooltips forward on the web. But please help me come up with a solution that works for WebKit. Hopefully "we don't know how to solve this" isn't how we leave this.

[mfreed7]

I just want to quickly mention that we've been discussing the touchscreen interaction pattern for the interesttarget attribute over on openui/open-ui#1052, and live in our weekly meetings, in case you'd like to provide some input to the process. It feels like we're honing in on a long-press activation strategy that might work well.

Absent any other feedback here, we are assuming "option #2" from my comment above is the required path to gaining WebKit's support for the broader hovercard/tooltip feature. Hopefully you can help us design something that is good for users and developers.

[annevk]

It's not clear to me how this integrates well with what platforms are doing today. If you end up with a situation where an end user would have to longpress once and then tap once to get the same UI a desktop user merely hovers for, it's not clear we are designing something that people actually want.

I suspect this is simply a case where standardization is happening too soon as there's no clear cross-platform solution and websites and apps also haven't really invested in alternatives thus far that have seen wide adoption. Tooltips have had almost two decades to come to mobile platforms and only now are we starting to see some of that and then only for certain elements with activation behavior.

[keithamus]

@annevk regardless of interesttarget or anything in that direction (such as longpress, new UI designs, or whatever), popover=hint is independently useful because websites which implement custom ephemeral floating UI cannot use popover=auto without closing other floating UI such as menus. This results in having to use popover=manual and a fairly significant amount of code to manage light dismiss (for example https://github.com/primer/react/blob/c424c36d50145371af67d0ff7a575dc5e4e30b7f/packages/react/src/TooltipV2/Tooltip.tsx#L210-L330). popover=hint provides quite a simple yet effective extension of popover by allowing a separate ephemeral stack. The only real difference between popover=hint and popover=auto is that opening a hint won't close auto popovers (but opening a popover=auto will close hints). This simple addition gives websites the capability to implement custom ephemeral floating UI succinctly and easily, without having to reimplement large parts of popover=auto.

So just to really dial into the point:

• popover=auto is very useful, but "one stack" - while coming very close to all of the funcionality an application needs - doesn't quite cut it as many applications have a "non ephemeral" set of floating UI (dialogs, menus), and an "ephemeral" set of floating UI (tooltips, hovercards).
• For desktop apps (forgetting mobile for a minute) - tooltips are a really common pattern, among other ephemeral floating UI. They're important for making accessible desktop applications with a good user experience.
• Right now to implement tooltips, you can't use popover=auto as it'll also close less-ephemeral floating UI, for example menus.
• Today we have to solve this by using popover=manual which means re-implementing the light dismiss that comes "for free" with popover=auto.
• popover=hint, in isolation, is a small extension which solves this problem, by offering a way to get popover=auto behaviour without closing adjacent popover=auto elements when opened.

[o-t-w]

I agree with others that hint should be considered separately of interesttarget, but seeing as the expressed concerns are about interesttarget, I want to say:

If you end up with a situation where an end user would have to longpress once and then tap once to get the same UI a desktop user merely hovers for, it's not clear we are designing something that people actually want.

@annevk The more common user experience on mobile will be just pressing the button. UX best practices strongly recommend against using tooltips for vital information. Tooltips are used for supplementary slightly useful hints, not essential tasks.

Even though we have lived in a mobile-first era for a long time now, workplace apps will always remain desktop first or even desktop only (e.g. Figma for web is desktop only, Photoshop for Web is desktop only, I worked on Gradle Enterprise, a complex app with lots of large tables where mobile was an afterthought as people use the app when they are at work). For that use-case, tooltips are a clearly established pattern that work well.

SwiftUI has a LongPressGesture, it's a well established interaction pattern on touchscreens. The native iOS Twitter/X app, for example, has several buttons that perform a different action on press vs long press. On the GitHub native app, you can leave an emoji reaction to comments by clicking an emoji. Long pressing the emoji shows which other users have left that same reaction. On iOS this is a smooth interaction that works flawlessly. On the web it is hit-and-miss, much of the time long press doesn't work. That experience could hopefully be improved if interesttarget was built into the web platform.

Tooltips remain ubiquitous in design systems and component libraries.