Is the order of slotchange events along a slot chain across node trees defined?

[trusktr]

I'm looking at #concept-node-insert and trying to understand the order in which slotchange events are fired on a chain of slots across node trees, where a "chain of slots" is a slot assigned to another slots assigned to another slot, across a tree of node trees.

You and I can glean from this fiddle that the order of slotchange events (in Chrome) happens from shallowest slot of root-most node tree to deepest slot of leaf-most node tree (see the console output).

I am trying to verify if this is in the spec; I don't want to rely on Chrome-only behavior that I've determined experimentally.

I am following this chain of links in the documentation: #concept-node-insert -> #assign-a-slot -> #assign-slotables -> #signal-a-slot-change -> #queue-a-mutation-observer-compound-microtask -> #notify-mutation-observers

However, the chain ends in firing a mutation observer compound microtask for the slot on which assign slotables happens.

This does explain how deeper slots which have shallower slots assigned to them have their slotchange events triggered when the assigned slotables of a shallow-most slot changes.

What I'm referring to, if you look at my fiddle, is that when the assign slotables algorithm runs, it triggers slotchange on all the slots despite the fact that a slot's slotables and slot’s assigned nodes are identical. A slotchange event is being fired along the chain of slots, and this is why we can use slot.assignedNodes({flatten:true}) with the flatten option to detect changes to the flattened assigned nodes anywhere along the chain when assign slotables happens on the head of the chain (in the root most node tree).

Is this described in the docs?

[rniwa]

This has been changed. Right now, a single slotchange event would be dispatched at the “shallowest” slot which is assigned to “deeper” slots. Note that mutation observers are the first to be informed because the step to notify mutation observers first invokes mutation observers before firing any slotchange events.

[trusktr]

I'm not sure I understand step 6.4 of https://dom.spec.whatwg.org/#concept-node-insert. I thought that might've been it, but it doesn't seem to traverse any node trees.

This has been changed. Right now, a single slotchange event would be dispatched at the “shallowest” slot which is assigned to “deeper” slots.

@rniwa Do you mean to say that the behavior we see in the fiddle is not specified in https://dom.spec.whatwg.org, and that the behavior may change in a future version of Chrome?

If this is the case (that the slotchange event will not propagate down a chain of slots from shallowest to deepest but rather only happen on the slot where assign slotables runs), then slot.assignedNode({flatten:true}) working the way it currently does (or as in #611) will be useless if "deeper" slots have no slotchange event by which some custom logic can use slot.assignedNode({flatten:true}) to determine final-distribution.

[trusktr]

On related note, what if there were two different events: slotchange for when the result of slot.assignedNodes() changes, and another one for when the result of slot.assignedNodes({flatten:true}) changes? Suppose it is called flatslotchange. This way, if performance is a concern, then the flatslotchange event would only fire if event listeners are registered, and same with slotchange.

[hayatoito]

Could you have a chance to take a look at DOM Standard carefully? I think you can find an answer there.

• If you need any further clarification for the spec, please file an issue for DOM Standard.
• If you find any spec-incompatible behavior in Blink, please file an issue for Blink.