handlers="..." declarative events listen on the host element and therefore see no event target info for events generated in shadowDom

[sorvell]

Because of upper bound encapsulation, event listeners installed on a component will get the component itself as the event target when an event is generated within its shadowDom. This is unfortunate since a component knows about its own shadowDom and should be able to get this target info.

For example, in g-ratings, it would be convenient to install a listener on the component and interrogate event.target to figure out which star was pressed. We cannot do so because the element node always has event.target set to itself.

We could address this by listening for events on the element's shadowRoot. This would, however, mean that events are relevant to a particular shadowRoot.

[sorvell]

Another alternative would be to install these events on the component's youngest shadowDom. In this case, because of event bubbling we would see events from anywhere inside the composed shadowDom. (When a < shadow > tag is used to host an inherited shadowDom and an event is generated within the inherited shadowDom, it will bubble to the containing shadowDom.)

However, again due to upper bound encapsulation, the event will be retargeted so that the event.target is the < shadow > element. And again, this is unfortunate because the component should be able to see this target info. It may be worth suggesting a change to shadowDom retargeting to avoid this as it's questionable whether upper bound encapsulation should function for a shadowDom stack.

This suggests that it's most natural for the handlers attribute to mean a component is interested in the shadowDom it generates itself and an extendor must redeclare interest in an event. If we go this way, perhaps we should attempt to move the handlers attribute to the component's shadowDom < template > tag.

[frankiefu]

This has been addressed, closing.