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

[jpzwarte]

There's also the use case where you invoke the popover programmatically (showPopover/togglePopover). Do you want to pass the anchor as an argument? Or just set it before calling the function?

popover.anchorElement = this;
popover.showPopover();

[jpzwarte]

So with CSS Anchor positioning, popoverInvoker doesn't necessarily have to be the same as anchorElement (assuming there will be an anchorElement property). So it probably doesn't make sense to set the popoverInvoker manually.

[jpzwarte]

@josepharhar So since a popovertarget will automatically become the implicit anchor for the popover (see w3c/csswg-drafts#8671 (comment)), wouldn't it be logical for the element with the popovertarget attribute to automatically be set as popover.anchorElement (or whatever name get's decided on)?

That way you can just use anchorElement instead of having to define something like popoverInvoker? And by changing anchorElement, you would also change the implicit anchor in CSS? cc @tabatkins

[mfreed7]

@josepharhar So since a popovertarget will automatically become the implicit anchor for the popover (see w3c/csswg-drafts#8671 (comment)), wouldn't it be logical for the element with the popovertarget attribute to automatically be set as popover.anchorElement (or whatever name get's decided on)?

The spec PR for this is in progress, but the plan is definitely not to make an element with popovertarget an implicit anchor. The idea is to use an anchor attribute on the popover to connect it to an implicit anchor. And then popover.anchorElement will return that anchor element. I think this makes a lot more sense than trying to use popovertarget because as has been mentioned above, there can be many of those, or none. There are either zero or one anchor attributes.

[jpzwarte]

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.

I'm looking at @oddbird/popover-polyfill again: I would like to use the polyfill and then use @floating-ui/dom in beforetoggle to position the popover relative to the invoker. However, just using the beforetoggle event, I have no idea what the invoker element is.

@mfreed7 Forgetting anchor related behavior for now, could we at least move to have the relatedTarget property of the beforetoggle event point to the invoker element when used declaratively? And also perhaps an { invoker: element } optional parameter to the show/hide/toggle functions?

[jpzwarte]

I went ahead and created a PR for the polyfill which adds this: oddbird/popover-polyfill#100

The only thing that I can see serious discussion on is that togglePopover(force?: boolean) changes to togglePopover(options?: { force?: boolean, invoker?: HTMLElement });. This would make it different from toggleAttribute.

[jpzwarte]

The spec PR for this is in progress, but the plan is definitely not to make an element with popovertarget an implicit anchor. The idea is to use an anchor attribute on the popover to connect it to an implicit anchor. And then popover.anchorElement will return that anchor element. I think this makes a lot more sense than trying to use popovertarget because as has been mentioned above, there can be many of those, or none. There are either zero or one anchor attributes.

So in your scenario both the button and popover would have to have DOM ids so they can point to each other: popovertarget to #popover and anchor to #button.
So I see the use case where a popover only has 1 button associated with it pretty common. Perhaps the most used actually. Does it make sense then that you have these elements pointing at each other? Would it not be a better DX to have the invoking button automatically become the implicit anchor?

[mfreed7]

So in your scenario both the button and popover would have to have DOM ids so they can point to each other: popovertarget to #popover and anchor to #button. So I see the use case where a popover only has 1 button associated with it pretty common. Perhaps the most used actually. Does it make sense then that you have these elements pointing at each other? Would it not be a better DX to have the invoking button automatically become the implicit anchor?

This is an interesting point. I suppose it would be pretty clean to make the active invoker element (i.e. the one that invoked the currently-open popover) an implicit anchor element, only if the popover doesn't also have an anchor attribute.

@xiaochengh @josepharhar @nt1m @annevk any objections/thoughts?

[josepharhar]

This is an interesting point. I suppose it would be pretty clean to make the active invoker element (i.e. the one that invoked the currently-open popover) an implicit anchor element, only if the popover doesn't also have an anchor attribute.

So popovers would by default just get anchored to their opener buttons? Sounds good to me I guess. Would there be a way to opt out of this?

I could spec this after the anchor attribute gets specced: #9144

Note: this was also suggested here, which contains examples that show why it may be nice to have: #9311

[jpzwarte]

So popovers would by default just get anchored to their opener buttons? Sounds good to me I guess. Would there be a way to opt out of this?

Any other anchor definition would cause you to opt out of this? So any CSS anchor,anchor attribute or anchorElement in JS?

[xiaochengh]

Any other anchor definition would cause you to opt out of this? So any CSS anchor,anchor attribute or anchorElement in JS?

Yes, that should be the recommended ways to opt out.

[domenic]

I see there is a PR for this in #10236.

Why is the name something vague like "relatedTarget"? That's basically just saying "an EventTarget related to the event", when I think you could be more specific about what the relation actually is. E.g. triggerer or invoker.

[LeaVerou]

Agreed with @domenic about making the property more specific. Consistency between InvokeEvent and ToggleEvent is also important here.

The InvokeEvent proposal currently includes an invoker property, which seems quite fitting here too. On <details> elements it can just point to the <summary> element.

[mfreed7]

I just wanted to call out the connection between this issue and #10442, plus the resolutions made this morning at the form controls task force. Those two links, respectively:

• propose adding popover.togglePopover({invoker: element})
• cause popovertarget (and the imperative API above) to create an "implicit anchor element" reference from the popover back to the invoker element, for anchor positioning.

Given that at least part of the request on this issue seemed related to anchor positioning - does the second bullet address the use case? If not, note that the first bullet (adding invoker to togglePopover) might be allowed to set an element that lives in a different shadow tree, but explicitly not if the invoker was retrievable through any other means, such as via the InvokeEvent event, or an IDL getter. Otherwise, that would expose the shadow tree.

So I guess my hope would be that we don't need to add an API to retrieve the invoker element?

@keithamus

[josepharhar]

Another use case for adding an invoker property to ToggleEvent would be to see which button a user clicked on to close a popover. I don't think that would be addressed by the anchoring related stuff.

I'm also not sure if the new invokers/commands proposal adds this capability or not.

[marco-prontera]

The current limitation of the toggleEvent is preventing Consent Management Platform (CMP) like ours to consider adopting Dialog or Popover to display Consent Management UIs on the Web.

Using these APIs can provide immediate benefits to CMP panels across the web, improving both accessibility and performance. However, there's a significant issue:

• When a button is clicked, we can't distinguish which button triggered the toggle event.

From my understanding, this limitation makes these APIs suitable only for simple use cases. If we had a way to identify the triggering button, it would enable more complex and flexible implementations.

Additionally, leveraging toggle or beforetoggle listeners could help mitigate Interaction to Next Paint (INP) performance issues that modal interactions can introduce. Since Popover and Dialog also inherently improve accessibility, addressing this issue would be a win-win for many developers working on similar use cases.

For now, a potential solution could be to use the Popover or Dialog APIs in combination with the click event and manage the modal state using the existing API. However, CMP JS SDK still need to ensure optimizations are made to prevent any INP issues.

So, the key problem statements are:

• Inside a popover or dialog, multiple buttons (n buttons) can exist. We need a way to determine which button initiated the hiding flow.
• Moreover, we need a way to check in advance whether the ToggleEvent supports a property like relatedTarget or something similar that could indicate which button caused the hiding flow.

[mfreed7]

Thanks for the comments. I'm supportive of adding something like invoker that points to the invoker on ToggleEvent. One challenge might be if that invoker resides in a shadow tree - we would likely have to retarget the invoker to the host element, like event.composedPath does.

[josepharhar]

I created a PR to add ToggleEvent.invoker here: #11186

[lukewarlow]

Some thoughts and questions (I haven't read the actual PR yet)

• Need to ensure we handle shadow roots properly
• Should ToggleEvent.source be HTMLElement or Element (for interest invokers it might need to be Element)
• Do we still need this? Is it aimed at the imperative API? (Command/commandfor already has this)
• Is the intention that dialog’s toggle event also sets source when set fired via command="show-modal”
• Should we allow passing a source to dialog.show() and dialog.showModal() (is this usecase interesting? Could we make it apply an implicit anchor positioning too?)
• What is ToggleEvent.source for a details element?

[josepharhar]

Need to ensure we handle shadow roots properly

The spec PR runs the retargeting algorithm to prevent leaking nodes in shadowroots.

Should ToggleEvent.source be HTMLElement or Element (for interest invokers it might need to be Element)

I don't have a preference, it sounds like Element is better. The spec PR currently uses Element.

Do we still need this? Is it aimed at the imperative API? (Command/commandfor already has this)

It is aimed at the declarative API, where the author wants to asynchronously know which button closed the popover via the toggle event.

Is the intention that dialog’s toggle event also sets source when set fired via command="show-modal”

Yes

Should we allow passing a source to dialog.show() and dialog.showModal() (is this usecase interesting? Could we make it apply an implicit anchor positioning too?)

I think that depends on what the source/invoker parameter for showPopover() was made for.

What is ToggleEvent.source for a details element?

If you use a command invoker element to toggle the details element, then it would be set to that command invoker button.

[lukewarlow]

What is ToggleEvent.source for a details element?

If you use a command invoker element to toggle the details element, then it would be set to that command invoker button.

What about the summary element? Does that get returned or just null?

[josepharhar]

What about the summary element? Does that get returned or just null?

Just null. Do you think it should return the summary element? I don't have an opinion on this.

[lukewarlow]

Just null. Do you think it should return the summary element? I don't have an opinion on this.

No strong opinions. I guess I'd think maybe it should be summary in the case that that's the source?

It is aimed at the declarative API, where the author wants to asynchronously know which button closed the popover via the toggle event.

Does this mean we should add the ability to do .hidePopover({source}) via imperative API?