Intent to Ship: Popover invoker and anchor positioning improvements

[Mason Freed]

Contact emails

mas...@chromium.org

Explainer

None

Specification

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

Summary

This chromestatus represents the following related set of changes, which were resolved in https://github.com/whatwg/html/pull/9144#issuecomment-2195095228 and landed in https://github.com/whatwg/html/pull/10728: 1. add an imperative way to set invoker relationships between popovers: popover.showPopover({source}) 2. invoker relationships create implicit anchor element references.

Blink component

Blink>DOM

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

The addition of `showPopover({source})` poses no compat risk, since it's a new capability. Making popover invokers into implicit anchor elements poses an extremely-small compat risk, in the case that a site: 1) uses popovertarget to invoke a popover 2) uses an anchor positioning property like `position-area` or the `anchor()` function, but critically *does not* use `position-anchor` or `anchor-name` to actually connect those properties between elements. 3) *relies* on there being no actual anchor positioning connection between the popover and the invoker. While this is certainly possible, it is very unlikely, especially given how recently anchor positioning shipped, in only Chromium browsers.

Gecko: No signal

WebKit: No signal

Web developers: No signals

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?

None

Debuggability

None

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

No

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

Yes

https://wpt.fyi/results/html/semantics/popovers/imperative-invokers.tentative.html https://wpt.fyi/results/css/css-anchor-position/popover-implicit-anchor.tentative.html

Flag name on about://flags

PopoverAnchorRelationships

Finch feature name

PopoverAnchorRelationships

Requires code in //chrome?

False

Tracking bug

https://crbug.com/364669918

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

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5120638407409664?gate=4720744823783424

Links to previous Intent discussions

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

This intent message was generated by Chrome Platform Status.

[Mike Taylor]

On 11/17/24 11:19 AM, Mason Freed wrote:

Contact emails

mas...@chromium.org

Explainer

None

Specification

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

Summary

This chromestatus represents the following related set of changes, which were resolved in https://github.com/whatwg/html/pull/9144#issuecomment-2195095228 and landed in https://github.com/whatwg/html/pull/10728: 1. add an imperative way to set invoker relationships between popovers: popover.showPopover({source}) 2. invoker relationships create implicit anchor element references.

Blink component

Blink>DOM

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

The addition of `showPopover({source})` poses no compat risk, since it's a new capability. Making popover invokers into implicit anchor elements poses an extremely-small compat risk, in the case that a site: 1) uses popovertarget to invoke a popover 2) uses an anchor positioning property like `position-area` or the `anchor()` function, but critically *does not* use `position-anchor` or `anchor-name` to actually connect those properties between elements. 3) *relies* on there being no actual anchor positioning connection between the popover and the invoker. While this is certainly possible, it is very unlikely, especially given how recently anchor positioning shipped, in only Chromium browsers.

Gecko: No signal

WebKit: No signal

Can we request signals from WebKit & Gecko (or do we already have them)?

--
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%3DNeDi9ZVzuBm8n7wiKRBzA8b23ZBWS18QK3OoL8-m7XN0C0g%40mail.gmail.com.

[Mason Freed]

On Tue, Nov 19, 2024 at 1:27 PM Mike Taylor <mike...@chromium.org> wrote:

Gecko: No signal

WebKit: No signal

Can we request signals from WebKit & Gecko (or do we already have them)?

Good callout, thanks. I just updated the chromestatus to add links and descriptions for implementer positions. This issue was discussed and resolved at the joint CSSWG/WHATWG/OpenUI task force meeting, which I've taken to mean we have implementer support. That met the bar for landing the WHATWG PR, so I was hoping it would work here too. 

 

Thanks,

Mason

[Mike Taylor]

Thanks for providing the links (and additional context).

LGTM1

[Domenic Denicola]

LGTM2.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/27a984e1-a65c-4939-943e-32ba679861c9%40chromium.org.

[TAMURA, Kent]

LGTM3

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

--

TAMURA Kent
Software Engineer, Google

[Mason Freed]

Thanks everyone!