search

WebKit / standards-positions

WebKit's positions on emerging web specifications
https://webkit.org/standards-positions/
240 stars 18 forks source link

popover=hint #305

Open mfreed7 opened 5 months ago

mfreed7 commented 5 months ago

WebKittens

No response

Title of the spec

popover=hint

URL to the spec

https://github.com/whatwg/html/pull/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

https://github.com/mozilla/standards-positions/issues/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, https://github.com/whatwg/html/issues/9776.

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

annevk commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

Some other thoughts upon reading more:

mfreed7 commented 5 months ago

Some other thoughts upon reading more:

Yeah, we discussed this at some length in OpenUI, in various places. But the main discussion is located here: https://github.com/openui/open-ui/issues/532. You'll note in my OP I agree with you that the primary use case is "tooltip" (and also in this comment https://github.com/openui/open-ui/issues/532#issuecomment-1192997498). 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 commented 5 months ago

@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 commented 5 months ago

@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 commented 4 months ago

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 commented 4 months ago

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 commented 2 months ago

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 commented 1 month ago

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