Re: [w3c/webcomponents] [Shadow] Slotting indirect children (#574)

Actually, I don't think parent should be a no-op, and I think the event
path will be almost the same: propagating up the shadow tree (any number of
levels deep), and now propagating up the light tree as well (*this part is
new*). The only difference is that the event propagated from the child to
its parent in the light tree. Now, it will simply propagate through all the
ancestors in the light tree. That's not a significant difference.

I have some examples to post in a bit, along with some use cases that are
limited by the current shadow dom spec, but I'm on my phone and need to
finish some manual labor. Will be back soon...

On Oct 4, 2016 9:32 PM, "Hayato Ito" <notifications@github.com> wrote:

> Adding a shadow to my-tab does not allow me to achieve the desired
> composed DOM (see the issue description). If the slot name exists as a slot
> in the direct parent, then it would behave as normal nested components.
>
> I have taken a look the composed DOM in the example, and now I understand
> why it is impossible. You are correct. Sorry for my misunderstanding.
>
> My opinions for this idea:
>
>    - I am not fan of this idea. If we allow that, markup (in children of
>    the shadow host) does not have meaning. That is not what we want, I think.
>
> For example, suppose that users write the following markup:
>
> <my-tabs>
>     <my-tab>
>         <my-tab-title>
>             Title 1
>         </my-tab-title>
>         <my-tab-content>
>             Content 1
>         </my-tab-content>
>     </my-tab>
>     <my-tba>
>         <my-tab-title>
>             Title 2
>         </my-tab-title>
>         <my-tab-content>
>             Content 2
>         </my-tab-content>
>     </my-tab>
> </my-tabs>
>
> I guess you did not notice the typo in the markup. They wrote <my-tba>,
> instead of <my-tab>. However, because this is still correctly rendered,
> regardless of the mistake, users would not notice their mistakes. That is
> not what we want to introduce to HTML world, I think. We want correct
> feedback by returning the wrong rendering result if the markup is wrong.
>
>    - This new idea should work with the rest of Shadow DOM APIs. For
>    example, how event path should be? The no-op parent should receive an event
>    which happens at its descendant which is assigned to a slot. But it is
>    difficult to have a nice answer how we can calculate an event path in this
>    case.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/w3c/webcomponents/issues/574#issuecomment-251578951>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AASKzm9gtEBN3nuS-A-FtSKusHe-uo1jks5qwydJgaJpZM4KFPC->
> .
>


-- 
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/574#issuecomment-251838596