Explanation:
The flattened DOM looks like this:
...
< grand-father >
#shadowRoot
< the-father >
#shadowRoot
< the-child >
#shadowRoot
< slot#child >
< slot#father >
< slot#grandFather >
matroska
Constructing this DOM produces six logs:
THE-CHILD: SLOT#father =>
THE-FATHER: SLOT#father =>
THE-CHILD: SLOT#child =>
THE-CHILD: SLOT#grandFather => matroska
THE-FATHER: SLOT#grandFather => matroska
GRAND-FATHER: SLOT#grandFather => matroska
A view of the DOM in which the three slotchange events are executed.
in-complete DOM completed DOM
< grand-father > § < grand-father > _
#shadowRoot § #shadowRoot *6
< the-father > _ § < the-father > |
#shadowRoot *2 § #shadowRoot *5
< the-child > | _ § < the-child > |
#shadowRoot *1 *3 § #shadowRoot *4
< slot#child > | ^ § < slot#child > |
< slot#father > ^ § < slot#father > |
< slot#grandFather > § < slot#grandFather > ^
"" § matroska
-
When log 1, 2, and 3 run, the DOM is in a temporary state.
The grand-father element is created, but it does not have any child nodes yet:
the "matroska" text node is not yet registered as its child.
This means that when the log functions run assignedNodes({flatten: true}), it is empty.
-
When log 4, 5, and 6 run, the DOM is completed. The "matroska" text node is now registered
as a child of the grand-father host element, and the assignedNodes({flatten: true})
return the anticipated result "matroska".