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

Revised my previous comment. 

I have a clearer picture after some testing. `slot.assignedNodes()` basically gives the literally assigned nodes on the context slot, while `slot.assignedNodes({flatten: true})` gives the distributed nodes at the context slot. However, `slot.assignedNodes({flatten: true})` returns nodes *even if the nodes have been further distributed to a deeper node*. This is similar to my previous `slot.distributedNodes()` idea, except that it doesn't return an empty array for the intermediate slots.

It might be nice to have a method (f.e. `slot.distributedNodes()` or `slot.assignedNodes({distributed: true})`) that when called on the slots S1 through S4 of my example will return distributed nodes only when called on S4. Does that make sense? 

For example, here's a jsfiddle showing S1 through S4 assigned nodes flattened: https://jsfiddle.net/trusktr/9bs9mryt/

The output looks like this:

```
slot change on s1: [p]
slot change on s2: [p]
slot change on s3: [p]
slot change on s4: [p]
```

If we had a new method for getting strictly finally  distributed nodes (`slot.distributedNodes()` or `slot.assignedNodes({distributed: true})`), the output would look like this:


```
slot change on s1: []
slot change on s2: []
slot change on s3: []
slot change on s4: [p]
```

where we see the final position of the `<p>` tag is at S4. If we were to unassign S3 from S4, then the output would be:

```
slot change on s1: []
slot change on s2: []
slot change on s3: [p]
slot change on s4: []
```

Get what I mean? I think that I believe that that would be useful for my case where I want to know the final positions where nodes are distributed.

I believe that I can currently achieve this by hijacking `attachShadow` so that I can always have shadow root references and by extension always have slot references, and then hack some way to find final distributions during `slotchange` events. Would love ideas on if there's some clean way to do it.

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

Received on Sunday, 27 November 2016 06:23:59 UTC