Re: [w3c/webcomponents] Need "slotchange" event (#288)

> I have explained how using mutation records could work and could be kept consistent with the mutation records we have today.

That depends on what you mean by "kept consistent".  As far as I'm concerned, the pinnacle of mutation observers is its ability to reconstruct the state of a DOM tree.  Using `childList` option, one can observe every child node inserted and removed from a parent.  With `slotchange`, only thing we can observe is that the list of distributed nodes have changed.  It doesn't tell us which nodes are added or removed into/from where.

Because of this, I'm opposed to using mutation observers unless the list of nodes that got inserted and removed are also provided.  But @hayatoito and I both agree that doing so would be prohibitively expensive in both Blink and WebKit so I don't think this is an option.

> Thanks to the `takeRecords()` feature it seems also the only approach that could explain synchronous layout features (apart from something that works exactly like it, but isn't mutation observers, of course).

No, you can't quite explain that since builtin elements update its layout/rendering synchronously when other DOM / CSS OM APIs forces a layout.  There is no mechanism by which custom elements can be notified to call `takeRecords()` in time.

> I've also explained how using animation frame timing does not fit with shadow DOM since it does not work for arbitrary node trees. I've explained how using normal tasks is problematic.

That's a fair point.  In that case, we probably just need to make it a synchronous event as @treshugart just implemented but I don't think Blink folks are amendable to implement this as a synchronous event since it would be expensive.

Finally, there is an option to implement this as an asynchronous event as I've done in WebKit.  However, you're opposed to that:
> And yes, if it's about updating UI queuing a task as you did is the wrong way to go, since UI can happen between tasks (and other tasks can happen between tasks, triggering yet more undesired effects).

So I don't see a way forward on this issue unless one of us changes his/her opinion and/or new evidence emerges that suggests one approach is better than others.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/288#issuecomment-203345289