Re: [w3c/webcomponents] DOM APIs which replace all children end up firing superfluous slotchange events (#764)

The principle of this problem is a bit tricky. Thinking out loud here of how I make sense of it.

When you construct the element, with children elements, and slotted children, it is a sequence of multiple actions. The inner constructor sets up elements with empty slottables in the first DOM constellation.
That triggers a slotchange event. Then the middle constructor sets up a second DOM constellation includes the inner element. That triggers a second slotchange event that bubbles to both the middle and inner slot element. Then the outer constructor sets up a third DOM constellation. That triggers a third slotchange event that bubbles to all three slot elements. 3 events fired. But 6 events caught. 3 events caught by the inner slot. 2 events by the middle. 1 event by the outer. And(!), in this case, and I think most such cases, the inner and middle slot is really only interested in the last slotchange event that they receive indirectly and that originates from the outermost slot.

Issue 1.
As a developer, I do not see the construction of a single custom element as the creation of a sequence of multiple DOM constellations. Although this is what the browser does, it took me a long time to envisage this DOM constellation sequence triggering 3 different slotchange events that bubble via the slots. And I am not sure I am right.

As a developer, I anticipate that the slotchange callback function of the two inner slots is only triggered once. I see the construction of this DOM branch as "a single slotchange moment". 
In this particular scenario, I would also anticipate that the assignedNodes of the inner elements never would be empty. And I would not have thought about efficiency concerns for the inner or middle slot listener callback due to them being called twice. 

Issue 2.
The last slotchange event that bubbles up to the innermost slot element, and that is the relevant slotchange event, does not originate from the innermost slot. That means that the event detail is confusing, as for example its .composedPath()[0] is the outermost slot.

If I attach the event listener for slotchange on the shadowRoot, and have multiple slots in my shadowRoot, I would have to search the event detail/ composedPath of the event detail to find the slot that is in my shadowRoot. If I simply assumed that .composedPath()[0] was the relevant slot element, and for example called .assignedNodes({flatten: true}) on it, then I could sometimes get the right data (as in this instance) and sometimes the wrong data (as more assigned nodes for that slot could be added in the middle layer).

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