Re: [whatwg/dom] Shadow: Specify when `slotchange` fires (#447)

@hayatoito, thanks for pointing this out. This is my mistake, I didn't read the spec carefully enough: I looked at [insert (step 6.4)](https://dom.spec.whatwg.org/#concept-node-insert) and [remove (step 11)](https://dom.spec.whatwg.org/#concept-node-remove), which call 'signal a slot change' depending on the number of assigned nodes of a slot for changes to *children* of that slot, and confused these with the responses to changes to the assigned nodes of the slot. So, I ended up overlooking ['assign slotables'](https://dom.spec.whatwg.org/#assign-slotables), which is where 'signal a slot change' for changes to assigned nodes really happens and, as you mentioned, for *any* change to assigned nodes. Anyway, I'm now pretty convinced that the behavior of `slotchange` isn't "deceptively incomplete". :)

@surma, [here's the MDN page on mutation events](https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Mutation_events); `slotchange` reminds me of them a bit and they were deprecated a while ago because of performance problems, but I can't really speak to the history there. In a sense `slotchange` acts as both `DOMNodeInserted` and `DOMNodeRemoved` because any insertion or removal could cause a `slotchange` if the parent inserted or removed from has a shadow root with a slot. Though, my guess is that `slotchange` is less expensive than these two events: mutation events had to be dispatched on any change to any node and bubble through the single tree containing all nodes in the document but `slotchange` is only dispatched when the parent of the child being moved has a shadow root containing a slot and bubbling is limited only to that parent's shadow root.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/447#issuecomment-302997182