Popover does not know what triggered it

[jpzwarte]

As far as I can tell from reading the spec, a popover doesn't know which element invoked it (a "trigger element").

Is this something that should be added?

I suppose this could be useful if the CSS Anchor positioning hasn't shipped yet, but popovers have. You could then use @floating-ui/dom for anchoring the popover. But that all depends on the popover knowing what triggered it.
Another example would be to style the trigger element when the popover is open.

One solution would be to specify the trigger when calling showPopover/togglePopover?

element.showPopover(this); or element.showPopover({ trigger: this });

[jpzwarte]

Afaict the CSS anchor proposal also doesn't support multiple popovertarget invokers: w3c/csswg-drafts#8671

[keithamus]

I agree this could be a useful addition. I think extending the ToggleEvent to include a relatedTarget property, which may be null or may be the invoking button. This would allow implementations to adjust the anchor on beforetoggle based on the relatedTarget, which seems to support the use case.

(BTW needs labels topic: popover The popover attribute and friends addition/proposal New features or enhancements )

[jpzwarte]

I'm just looking at @oddbird/popover-polyfill and I'm running into this issue. Afaics there is no way to know what triggered the popover, so I have no information I can use to position the popover with @floating-ui/dom.

@keithamus How can I get the right set of eyes on this issue? Any tips? Or just patience? :)

[jpzwarte]

There is mention of an anchor attribute in the OpenUI research explainer: https://open-ui.org/components/popover.research.explainer/#anchoring

The only thing I can find in the spec is this line: "(e.g., a popover with an anchor attribute that points back to the same popover)"

A logical followup of that might be an anchorElement property?

[keithamus]

@mfreed7 or @josepharhar might want to give this some attention.

[keithamus]

There is mention of an anchor attribute in the OpenUI research explainer

CSS anchoring is a separate spec to popover. Here's an explainer: https://developer.chrome.com/blog/tether-elements-to-each-other-with-css-anchor-positioning/

[jpzwarte]

CSS anchoring is a separate spec to popover. Here's an explainer: https://developer.chrome.com/blog/tether-elements-to-each-other-with-css-anchor-positioning/

I can't find any mention of an "attribute" here https://w3c.github.io/csswg-drafts/css-anchor-position/

The only thing specific to popover is this: "The Popover API, for example, defines an implicit anchor element for a popover—the element that the popover is attached to."

[keithamus]

It looks like the anchor attribute wasn't pursued, in favour of using a name reference in CSS.

[josepharhar]

I am going to open a HTML spec PR for the anchor attribute soon.

If we added a new IDL like element.popoverInvoker which returned the element which is pointing to the popover element via popovertarget, would that be good enough?

I agree this could be a useful addition. I think extending the ToggleEvent to include a relatedTarget property, which may be null or may be the invoking button. This would allow implementations to adjust the anchor on beforetoggle based on the relatedTarget, which seems to support the use case.

Is having multiple potential invoking buttons and knowing which particular one opened it essential to this use case?

[keithamus]

popoverInvoker doesn’t seem right to me because there can be many invokers (so which one would it return?), and it also wouldn’t be able to track the most recently used one. A relatedTarget on the event can also be null if the popover was opened via JS which can also be a useful signal).

I’m unsure if it’s @jpzwarte’s usecase but I can definitely imagine use cases of multiple buttons accessing a shared popover, and switching the anchor to the most currently used button.

[jpzwarte]

I’m unsure if it’s @jpzwarte’s usecase but I can definitely imagine use cases of multiple buttons accessing a shared popover, and switching the anchor to the most currently used button.

Yes, that's my usecase.

I understand that the CSS Anchor Positioning will handle this on its own (a popover will have an implicit anchor based on popovertarget), but we also need something on the DOM side of things. For example to display data related to the popovertarget in the popover. For that to work, you need to know which button invoked the popover.

[josepharhar]

I see, then adding relatedTarget to ToggleEvent would be good enough.

We could also make element.popoverInvoker only return the most recently used invoker, and set it to null while the popover is closed or when it is opened via script. If it is set prior to dispatching the beforetoggle event, then script could also access it when needed without the need to add it to ToggleEvent.

[josepharhar]

Making element.popoverInvoker return the existing popover invoker would be quite easy