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

@surma Thanks.

> I think those scenarios exist, where cleanup is desirable and/or necessary. (E.g. Setting/Unsetting aria-activedescandant.)

Yeah, I can imagine. :) 
In addition to that, I am a little worrying about that a slotchange event for removal case would be a *noise* for a slotchange event listener because a slotchange listener wouldn't be interested in slotchange for "removal case" in most cases because its assigned nodes is always empty, and the slot was already disconnected from the (custom element's) shadow tree when they receive a slotchange.

It would be great if we can see the concrete example of the current usage of a slotchange event listener.

I guess it would be something like:
```javascript
slot.addEventListener('slotchange', (e) => {
  // ...
  for (const slotable of slot.assignedNodes()) {
    // do some task for slotable
  }
}
```

, right? If so, I don't worry much.

> I have no hard numbers, but from experience I’d say that performance does not need to be a concern here. Removing slots from a Shadow Root is pretty rare – I have never seen or done it. Maybe @sorvell or @kevinpschaaf can provide additional insight.

I think it would be difficult to have hard numbers. :) So we don't need to try to get hard numbers strictly.
Rough feeling would be enough, which I had to double-check.

>From the implementor's perspective, since the slot was already disconnected from the tree, I need some time to know its feasibility to support it nicely. It is different from other cases.

In any cases, I think we can land  https://github.com/whatwg/dom/pull/459 separately, which shouldn't be blocked on the discussion. That is the reason I suggested to file a separate issue so that the discussion shouldn't block the https://github.com/whatwg/dom/pull/459.


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