Intent to Ship: popover=hint

[Mason Freed]

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 desktop	133
Shipping on Android	133
Shipping on WebView	133

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]

On 11/11/24 2:30 PM, Mason Freed wrote:

Contact emails

mas...@chromium.org

Explainer

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

Specification

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

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]

On Fri, Nov 15, 2024 at 9:20 AM Mike Taylor <mike...@chromium.org> wrote:

Specification

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

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.

 

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.)

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]

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]

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

[Mason Freed]

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]

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

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDigYHVDQSEmv3rHKf4VN0qRwqF91gYfzE5qSwKX7PwmZg%40mail.gmail.com.

[Mason Freed]

Thanks everyone.