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

No response

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.