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)

Working through the logic I proposed in https://github.com/WICG/webcomponents/issues/1098#issuecomment-2800523352 with some examples:

#### button with `popovertarget` outside of shadow root referring to `popover` element via reference target

From https://github.com/whatwg/html/issues/10707#issuecomment-2757756980

```html
<button id="button" popovertarget="component">…</button>
<component-a id="component">
  <template shadowrootmode="closed" shadowrootreferencetarget="innerPopover">
    <div id="innerPopover" popover>…</div>
  </template>
</component-a>
```

1. User clicks `button`.
2. The button [activation behaviour](https://html.spec.whatwg.org/multipage/form-elements.html#the-button-element:activation-behaviour) algorithm falls through to [Step 6](https://html.spec.whatwg.org/multipage/form-elements.html#the-button-element:popover-target-attribute-activation-behavior):
   > run the popover target attribute activation behavior given _element_ and _event_'s target 
   
    _element_ and _event_'s target are both `button`, because _event_ is the click event on `button`.
3. The [popover target attribute activation behavior](https://html.spec.whatwg.org/multipage/popover.html#popover-target-attribute-activation-behavior) algorithm takes `button` as the value for both _node_ and _eventTarget_.
4. Let _popover_ be `button`'s popover target element -> _popover_ is now `innerPopover` (via the reference target).
5. Assuming the popover wasn't already showing, the algorithm falls through to [step 7](https://html.spec.whatwg.org/multipage/popover.html#the-popover-target-attributes:show-popover):
   > run show popover given _popover_, false, and _node_.
   
   _popover_ being `innerPopover` and _node_ being `button`.
6. In [show popover](https://html.spec.whatwg.org/multipage/popover.html#show-popover), _element_ is `innerPopover` and _invoker_ is `button`.
7. 🆕 In [step 9](https://html.spec.whatwg.org/multipage/popover.html#the-popover-attribute:event-beforetoggle), we would need to pass _invoker_ i.e. `button` as the "trigger element" (let's just call it the invoker, eh?) to the [fire an event](https://dom.spec.whatwg.org/#concept-event-fire) algorithm - something like "with the `invoker` attribute initialized to _invoker_".
8. 🆕 In [fire an event](https://dom.spec.whatwg.org/#concept-event-fire), the invoker is part of the initialization of `event` in step 4.
9. 🆕 In [event dispatch](https://dom.spec.whatwg.org/#concept-event-dispatch), we now get an _invoker_ as part of _event_.
10. In [step 6.8](https://dom.spec.whatwg.org/#ref-for-get-the-parent%E2%91%A2) and [step 6.9.9].(https://dom.spec.whatwg.org/#ref-for-get-the-parent%E2%91%A3), the algorithm calls into [get the parent](https://dom.spec.whatwg.org/#get-the-parent) with _event_.
11. When [a node's get the parent](https://dom.spec.whatwg.org/#ref-for-get-the-parent%E2%91%A4) is invoked on `innerPopover`, it returns the shadow root as normal.
12. 🆕 When [a shadow root's get the parent](https://dom.spec.whatwg.org/#ref-for-get-the-parent%E2%91%A6) is invoked on the shadow root, we go to the new logic:
   > 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 an invoker, and _event_'s invoker'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.
   
   so _target_ is `innerPopover`; shadow root _is_ the root of _target_; event has an invoker, `button`; so, we return the result of retargeting `innerPopover` against `button`, yielding `component` as the parent element.
13. 🆕 Back in event dispatch where the path would previously have just been [`innerPopover`, shadow root], it now goes [`innerPopover`, shadow root, `component`, [... component's light DOM ancestor chain]] (I think).
14. Event dispatch continues as normal with the given event path
15. 🆕 If [`composedPath()`](https://dom.spec.whatwg.org/#dom-event-composedpath) is called on _event_, it now also uses the new path including `component` and its light DOM ancestors.

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

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