Contact emailsmas...@chromium.org

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

Specificationhttps://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 componentBlink>HTML>Popover
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EHTML%3EPopover>

TAG review

TAG review statusPending

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
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
?Yes

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


Flag name on about://flagsExperimental Web Platform Features

Finch feature nameHTMLPopoverHint

Requires code in //chrome?False

Tracking bughttps://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 discussionsIntent 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
<https://chromestatus.com/>.

-- 
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+unsubscr...@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.

Reply via email to