DOM APIs which replace all children end up firing superfluous slotchange events

[rniwa]

When replacing all children of a node, via textContent for example, removing each child of the node results in the invocation of the concept to assign slotables for a tree.

For example, consider the following shadow tree:
<p id="target"><slot id="slot1"></slot><slot id="slot2"></slot><slot id="slot3"></slot></p>

If target.textContent = '' is evaluated, it would result in the removal of slot1, followed by that of slot2 and slot3. As a result, we would fire slotchange event on slot2 and slot3 despite of the fact those slots would have never been "rendered" with assigned nodes in practice.

This results in slotchange event handlers of slot2 and slot3 potentially doing unnecessary & useless work.

Relatedly, Firefox's implementation seems to fire slotchange on slot2 & slot3 when target.remove() is evaluated, which seems wrong because the time at which the concept to assign slotables for a tree is evaluated, slot2 and slot3 are no longer in the tree.

See https://gist.github.com/rniwa/1a24c77317a50785ae8885e58f35966c for the demo.

[rniwa]

@annevk @domenic @JanMiksovsky @hayatoito @travisleithead @sorvell

[hayatoito]

It looks an expected behavior to me; Fire slotchange events on every slots if their assigned nodes are changed.

I wonder what is a practical issue for the current expected behavior? Could you share that with us?

Unless there is a strong practical issue, I would prefer a consistent behavior.

[emilio]

cc @smaug----

[smaug----]

Ok, Gecko may have an issue, but other than that, looks reasonable and consistent.

[rniwa]

The issue here is that slot elements get superfluous slotchange events which are of no use. The fact replace all is implemented as a sequence of removing each node is more of a spec fiction. The author shouldn't have to deal with it. There is also a serious performance cost in firing slotchange event on all those slot elements. In fact, if we were to implement this in WebKit, we would slow down all operations of replace all so it's simply not acceptable. As such, the WebKit team would object to the currently specified behavior.

Note that neither Gecko nor WebKit implement the currently specified behavior, and Chrome doesn't fire slotchange in the tree order in other cases. It just so happens to match this particular spec behavior but the order of elements in other cases are not spec conforming.

[hayatoito]

Thanks. So the expected behavior from the author's perspective would be:

shadowRoot: <p><slot id="slot1"></slot><b><slot id="slot2"></slot></b><slot id="slot3"></slot></p>
Removing p results in slotchange events on: ["slot1"]
shadowRoot: <p><slot id="slot1"></slot><slot id="slot2"></slot><slot id="slot3"></slot></p>
Setting p.textContent to "" results in slotchange events on: ["slot1"]

, right? (Both cases fire a slotchange event only on slot1). I agree that this behavior looks consistent from the autors' perspective.

From the spec's perspective, can the spec (or maybe the implementation too?) become complicated if we try to align the current spec to the author's expected behavior?

[rniwa]

@hayatoito : I think implementation / spec just needs to special-case replace-all case, e.g. add a flag to the concept to remove a node similar to an optional suppress observers flag and skip steps 12, 12.1 and 12.2 which assign spottables for a tree. replace all would then invoke it later.

It would add a slight complexity but I think it's an overall win for developer ergonomics & perf since resolving slots after removing each subtree is very expensive.

[annevk]

What exactly would replace all invoke? "Run assign slotables for a tree with parent's root."? Or node's root? I guess they're always equivalent if we do this at the end. Presumably we would have to adjust the insert operation as well, which also has a suppress observers flag? Or is the "problem" non-existent there somehow? (Unfortunately I don't have all the logic in my head anymore, I hope you all don't mind the questions.)

[caridy]

cc @ekashida

[rniwa]

We'd have to run assign slotables for a tree with parent’s root, and then run it again for the children we just removed.