Explanation:
First, the flattened DOM looks like this:
...
< the-father >
#shadowRoot * slotchange listener
< the-child >
#shadowRoot * slotchange listener
< slot#child >
< slot#father >
matroska
Take note of two things:
-
The slot elements appear in reverse document order.
-
The slotchange event listeners are attached to the #shadowRoot of each element.
This causes the inner web component to be triggered first and then the outer web component.
-
If the slotchange event listener were attached to the slot elements instead,
then they would run in reverse document order.
Creating this DOM produces three logs:
THE-CHILD SLOT#child
THE-CHILD SLOT#father
THE-FATHER SLOT#father
-
The first log output comes from slot#father being transposed into slot#child.
The event start bubbling from the slot#child, is then caught by the event listener on the-child#shadowRoot,
and finally stopped by the border between < the-child > host element and its #shadowRoot.
...
< the-father >
#shadowRoot
< the-child > _
#shadowRoot *1
< slot#child > slotchange ^
< slot#father >
matroska
-
The second and third log output is produced by the same(!) slotchange event.
The event occurs when the "matroska" text node is being transposed into slot#father.
The event then bubbles up, and because it is "composed: false", it is stopped by the border
between the-child and its #shadowRoot. However, because the slot elements remain in the flattened
DOM in reverse document order as a SlotMatroska, the slotchange event listener on both the
the-father and the-child element are triggered. Producing two outputs.
...
< the-father > _
#shadowRoot *3
< the-child > |
#shadowRoot *2
< slot#child > |
< slot#father >slotchange ^
matroska