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.

Note that the spec PR is slightly out of date and is being updated to include the "hint stack" concept.

[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?