Re: [WICG/webcomponents] Options for controlling specifics of "slotchange" events? (#933)

> IMO, this behavior is correct and acceptable, albeit sometimes inconvenient.

I agree that this is both "correct" and acceptable, beyond the gotcha that updating a node's `textContent` doesn't add/remove that node and as such does not trigger an `slotchange` event.

---

I also feel that applying directly on the `<slot>` element is likely the best path forward (where this taken up), but I wanted to include as many options as I could think of to make sure we didn't get stuck in a single yes/no conversation. I'd also go so far to say that if it weren't declarative (don't shoot, I'm unarmed) and you could only apply this imperatively, that could understand not wanting to pollute the attribute space. I'm not sure that's possible now, with the Declarative Shadow DOM spec as far along as it is, but I'm not closed to the option.

---

As for applying this functionality in user code (a version of polyfilling that doesn't imply that browsers _will_ adopt or that the feature is somehow "not done" until they do), it is relatively straight forward. Its tight proximity to the capabilities of `slotchange` are what lead me to this conversation, over and over again, however.

---

> the concept of customizing when or how events are emitted through options and/or attributes feels a bit weird. I can't think of any other APIs that work like this.

To help broaden my scope of knowledge, are there any other elements that both observe their "children" and report changes to those children in the platform today? I understand the `slotchange` event to represent a fairly unique (if not wholly unique) capability, and in that way feel like there's less of a "let's align with the rest of the platform" responsibility here. It could be that uniqueness (and it's association to the MutationEvent API) that prevents innovation in this area. Were that the case, maybe we should look at alternative APIs that were more likely to grow with the platform?

In that way, I'd say that while it doesn't report the changes to the outside that the `<select>` element already observes its children for changes beyond `childList`. It's likely not leveraging Mutation Observer, but if it were, it would absolutely require `subtree`, `characterData`, and maybe more to reactively update the UI it delivers when selected options have their light DOM content change. Maybe there's something to be learned there around internals as yet not surfaced to developers?

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