Re: [WICG/webcomponents] Reference Target: How to handle events fired on the reference target by related elements? (Issue #1098)

alice left a comment (WICG/webcomponents#1098)

Thanks for the example @Westbrook, that helps a lot.

I think your idea:

> add a "referenced" event that rather than composing through the whole DOM tree created an event path that only included the host and the target elements, and as such listing only those two in its `composedPath()`

seems like a pretty good starting point.

I think for my question above, I would say that in the second case the event *shouldn't* be "referenced" - i.e. that because the submit action doesn't come from outside the shadow root, the event should stay within.

Likewise, for your example, if we changed it to something like:

```html
<x-popover id="popover">
  <template shadowRootMode="open" referenceTarget="container">
    <style>
      #container {
        /* completely encapsulated styles for the popover */
      }
    </style>
    <button popovertarget="popover">Toggle</button>
    <div id="container" popover>
     Popover content.
    </div>
  </template>
</x-popover>
```

Where there is still a `referenceTarget` pointing at the popover, but the button inside of the shadow root is actually what is used to toggle it, then the event should stay within the shadow root.

To that end, I think we might want _something_ like:
- Add a "trigger element" alongside [target](https://dom.spec.whatwg.org/#event-target) 
- Set the "trigger element" for events which are specifically triggered via attribute-associated elements (see below)
- Modify shadow root's [get the parent](https://dom.spec.whatwg.org/#ref-for-get-the-parent%E2%91%A6) algorithm to something like:
   1. let _target_ be event’s path’s first struct’s invocation target;
   2. if event’s composed flag is set, or shadow root is not the root of _target_, return return shadow root’s host; 
   3. otherwise, if event has a triggering element, and event's triggering element's root is a shadow-including ancestor of shadow root, return the result of retargeting _target_ against event's triggering element;
   4. otherwise, return null.

That's a pretty quick and dirty sketch, but I think something like that would work? The idea of step 3 is to retarget _target_ only if the triggering element is associated via reference target, i.e. if the triggering element uses something like `popoverTargetElement` from deeper shadow DOM, it should return null.

Some places we'd need to modify the call into the event dispatch algorithm:
   -  [form submission](https://html.spec.whatwg.org/#form-submission-algorithm:event-submit) with _submitter_ as the trigger element
   - [show popover](https://html.spec.whatwg.org/multipage/popover.html#show-popover) when _invoker_ is not null, with _invoker_ as the trigger element
   - [dialog invoker command steps](https://html.spec.whatwg.org/multipage/interactive-elements.html#the-dialog-element:invoker-command-steps) leads to two potential algorithms which would both need to be updated to include the triggering element:
     - [show a modal dialog](https://html.spec.whatwg.org/multipage/interactive-elements.html#show-a-modal-dialog)
     - [close the dialog](https://html.spec.whatwg.org/multipage/interactive-elements.html#close-the-dialog)
     - These each fire a `beforetoggle` event and [queue a dialog toggle event task](https://html.spec.whatwg.org/multipage/interactive-elements.html#queue-a-dialog-toggle-event-task)
   - [custom command on `<button>`](https://html.spec.whatwg.org/multipage/form-elements.html#the-button-element:event-command-2), with _source_ as the trigger element

-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/1098#issuecomment-2800523352
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/1098/2800523352@github.com>

Received on Monday, 14 April 2025 05:37:55 UTC