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.