Intent to Ship: popover=hint

307 views
Skip to first unread message

Mason Freed

unread,
Nov 11, 2024, 2:31:27 PMNov 11
to blink-dev

Contact emails

mas...@chromium.org

Explainer

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

Specification

https://github.com/whatwg/html/pull/9778

Summary

The Popover API (https://chromestatus.com/feature/5463833265045504) specifies the behavior for two values of the `popover` attribute: `auto` and `manual`. This feature describes a third value, `popover=hint`. Hints, which are most often associated with "tooltip" type behaviors, have slightly different behaviors. Primarily, the difference is that `hint`s are subordinate to `auto`s when opening nested stacks of popovers. So it is possible to open an unrelated `hint` popover while an existing stack of `auto` popovers stays open. The canonical example is that a <select> picker is open (popover=auto) and a hover-triggered tooltip (popover=hint) is shown. That action does not close the <select> picker.



Blink component

Blink>HTML>Popover

TAG review



TAG review status

Pending

Risks



Interoperability and Compatibility

Since this is a new value for `popover`, there should not be any compat risks.



Gecko: Positive (https://github.com/mozilla/standards-positions/issues/965)

WebKit: Negative (https://github.com/WebKit/standards-positions/issues/305) Apple is negative, because they see this feature as inextricably tied to the `interesttarget` feature.

Web developers: Positive (https://github.com/openui/open-ui/issues/1114#issuecomment-2463048194) I specifically discussed the utility of this feature with the developer community, at several OpenUI meetings. The response was overwhelmingly supportive of this feature in isolation, even without `interesttarget`. Developers think that it removes the burden of implementing all of the popover light dismiss behaviors themselves on `popover=manual` popovers, which is the only way to implement hovercards/tooltips today using popovers, if they want to avoid bad interactions with `popover=auto` popovers.

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?



Debuggability



Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

https://wpt.fyi/results/html/semantics/popovers



Flag name on about://flags

Experimental Web Platform Features

Finch feature name

HTMLPopoverHint

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1416284

Estimated milestones

Shipping on desktop133
Shipping on Android133
Shipping on WebView133


Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5073251081912320?gate=5177431016603648

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDgd1JZuBkpHud7QsJchZVOr0mDMZxWch1enf%3DuyU98QCw%40mail.gmail.com


This intent message was generated by Chrome Platform Status.

Mike Taylor

unread,
Nov 15, 2024, 12:20:25 PMNov 15
to Mason Freed, blink-dev


On 11/11/24 2:30 PM, Mason Freed wrote:
I see that WebKit is opposed to landing this PR. I don't fully understand the objection - there are other instances of different UX patterns between Desktop and Mobile that users seem to understand - e.g., pull to refresh vs ctrl/cmd-r - so thank you for asking for more specifics some 3 weeks ago.



Summary

The Popover API (https://chromestatus.com/feature/5463833265045504) specifies the behavior for two values of the `popover` attribute: `auto` and `manual`. This feature describes a third value, `popover=hint`. Hints, which are most often associated with "tooltip" type behaviors, have slightly different behaviors. Primarily, the difference is that `hint`s are subordinate to `auto`s when opening nested stacks of popovers. So it is possible to open an unrelated `hint` popover while an existing stack of `auto` popovers stays open. The canonical example is that a <select> picker is open (popover=auto) and a hover-triggered tooltip (popover=hint) is shown. That action does not close the <select> picker.



Blink component

Blink>HTML>Popover

TAG review

Is it worth asking TAG for input here? Or have they already given it?


TAG review status

Pending

Risks



Interoperability and Compatibility

Since this is a new value for `popover`, there should not be any compat risks.



Gecko: Positive (https://github.com/mozilla/standards-positions/issues/965)
(non-blocking note here: I see there was a patch submitted 5 months ago, but there hasn't been any visible activity around it. I wonder why.)
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDgzF-L9OSyr6sdarJHD-2UFPZ0D3Bvus53v-bXKxwRXyA%40mail.gmail.com.

Mason Freed

unread,
Nov 15, 2024, 12:54:32 PMNov 15
to Mike Taylor, blink-dev
On Fri, Nov 15, 2024 at 9:20 AM Mike Taylor <mike...@chromium.org> wrote:
I see that WebKit is opposed to landing this PR. I don't fully understand the objection - there are other instances of different UX patterns between Desktop and Mobile that users seem to understand - e.g., pull to refresh vs ctrl/cmd-r - so thank you for asking for more specifics some 3 weeks ago.
👍
 

TAG review

Is it worth asking TAG for input here? Or have they already given it?

So the original popover API included this feature (`popover=hint`). That original API had not just one, but three TAG reviews (1, 2, 3), and 2.5 of them included the `popover=hint` behavior. I was hoping I reached my TAG quota and could avoid another review. LMK if that makes sense.
 
(non-blocking note here: I see there was a patch submitted 5 months ago, but there hasn't been any visible activity around it. I wonder why.)

I'm guessing (without evidence) that this is because of the Webkit-induced uncertainty around this feature. I'm hoping this I2S alleviates some of that uncertainty. I think this is a good feature, and Mozilla and developers both seem to agree.

Thanks,
Mason

Domenic Denicola

unread,
Nov 18, 2024, 2:49:17 AMNov 18
to blink-dev, Mason Freed, blink-dev, Mike Taylor
LGTM1.

Thanks for giving more details on the TAG review; when I first saw this Intent go out I was surprised by that field being empty as it mismatched my memory. I agree that this feature has seen enough TAG discussion.

The only open spec issue I found related to this feature is https://github.com/openui/open-ui/issues/781 which I don't believe is blocking.

I think it's unfortunate that Apple is opposed to this feature, but I agree that there is strong reasoning and web developer support for shipping it. In particular it seems multiple folks have attempted to address Apple's objections about hover patterns, pointing out that popover=hint can be used independently of hover patterns. I hope that the community produces nice polyfills for this additional attribute state so that web users and developers can get the benefits of this feature regardless.



To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Mike Taylor

unread,
Nov 18, 2024, 11:30:33 AMNov 18
to Domenic Denicola, blink-dev, Mason Freed

LGTM2 - I agree that the use cases are compelling and see there is significant demand for popover=hint.

Mason Freed

unread,
Nov 18, 2024, 12:07:21 PMNov 18
to Mike Taylor, Domenic Denicola, blink-dev
Thanks for the LGTMs. One comment...

On Mon, Nov 18, 2024 at 8:30 AM Mike Taylor <mike...@chromium.org> wrote:

LGTM2 - I agree that the use cases are compelling and see there is significant demand for popover=hint.

On 11/18/24 2:49 AM, Domenic Denicola wrote:
LGTM1.

The only open spec issue I found related to this feature is https://github.com/openui/open-ui/issues/781 which I don't believe is blocking.
Thanks for asking about that one. I just re-titled it, since it's actually related to `interesttarget` (about the delays in showing and hiding after "interest" is shown/lost). But thanks for making sure!

Thanks,
Mason

 
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Daniel Bratell

unread,
Nov 20, 2024, 10:57:36 AMNov 20
to Mason Freed, Mike Taylor, Domenic Denicola, blink-dev

LGTM3

I see Apple's concerns about this being not great for mobile devices with current UI models, but the value to devices that have useful pointer devices seems great enough to motivate shipping it anyway.

/Daniel

Mason Freed

unread,
Nov 20, 2024, 11:51:46 AMNov 20
to Daniel Bratell, Mike Taylor, Domenic Denicola, blink-dev
Thanks everyone.
Reply all
Reply to author
Forward
0 new messages