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

 **Note**: While preparing a demo for this reply, I found out that things become even more inconsistent depending on whether you create your slots in the constructor or `connectedCallback`. I augmented the original table!

| | Slots in constructor, parser creates element  | Slots in constructor, element gets upgraded | Slots in `connectedCallback`, parser creates element | Slots in `connectedCallback`, element gets upgraded |
|-|----|---|---|---|
|Chrome| Fire | No fire | Fire | No Fire |
|Safari| Fire | No fire | No Fire | No Fire |
|ShadyDOM| Fire | Fire | Fire | Fire |

---

@hayatoito Thanks for investigating. Very glad to hear that the behavior is technically possible and feasible.

@rniwa As I said, my main goal is consistency, with a preference for changing the behavior to always firing `slotchange`. Let me address these two things separately:

## Consistency
The behavior of `slotchange` depends on:

* Whether you define your element before or after using the element (upgrade vs parser creation)
* Whether you define your slots in the constructor or `connectedCallback`

Unless you are intimately familiar with the intricacies of Custom Elements and ShadowDOM, this is going to trip up and annoy developers. When developing generic components, you might write code that works fine during development, but because users include your CE script at a different point in the page, things suddenly stop working. 

A similar argument can be made for `slotchange` behaving differently depending on whether you create the slot in the constructor or in `connectedCallback`.

## Always firing
Take a look at this [demo](https://jsbin.com/liveko/9/edit?html,output), which is a stripped down version of a tab panel component I am working on. I’m using ShadowDOM to “reshuffle” the children as a technique for graceful degradation. If JS is disabled, the tabs function as headings for the different sections. So in the markup tabs and panels are interleaved. I use ShadowDOM do group tabs and panels.

I need to be notified about new elements because I need to generate IDs and semantically link tabs and panels using `aria-controls` and `aria-labelledby`. Right now, I’d have to manually call into the linking code in the `connectedCallback()` in addition to linking it to the `slotchange` event.

I am aware that CE lifecycle callbacks are something different from ShadowDOM events, but the fact that `attributeChangedCallback` _does_ get called for initialization purposes and `slotchange` does not, is confusing and somewhat unexpected. A MutationObserver would help, but ShadowDOM already has an internal MO so I think it’d be nice to be able to make use of that (apart from clearing up the aforementioned inconsistency with `attributeChangeCallback`). 


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