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

Sorry about the late response; I think other folks here pretty much covered what I would have said though. I can only provide anecdotal evidence that the elements I've worked on don't often (ever?) rearrange their shadow tree in a way that causes their slot(s) to be removed. Most of the time, they clone and append the content of some template and that shadow tree's structure remains largely the same throughout the element's lifetime.

On a related note, after reading through the earlier comments on this thread and the related sections of the spec in a bit more detail, I learned that this event is *only* dispatched when the number of nodes assigned to a slot changes between zero and some non-zero amount. Was this a recent addition? I was under the impression that this event fired whenever the assigned nodes of a slot changed in any way, so I'm not sure I understand what the intended use of `slotchange` is anymore. If it isn't meant to be a way to synchronously respond to all distribution changes, what is it?

I could understand if `slotchange` raises the same concerns as mutation events (given that it's effectively a subset) and why that might have caused the spec change but the value seems to have been lost. If this concept is still too slow to be implemented in earnest - even with the limited scope of `slotchange` - maybe it should be abandoned altogether. I'd rather have no API than a deceptively incomplete one. A custom element author could always use a MutationObserver or override `appendChild`, `removeChild`, `insertBefore`, etc. so long as they're willing to find a reasonable workaround for children inserted during parsing or deep cloning.

-- 
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-302848196