I'd like this API to stay simple for v1 and support only named slots and not tag names. I believe we can explain what <details> does with the imperative API in v2.
On Mon, May 18, 2015 at 5:11 PM, Justin Fagnani <justinfagn...@google.com> wrote: > > > On Mon, May 18, 2015 at 4:58 PM, Philip Walton <phi...@philipwalton.com> > wrote: > >> Pardon my question if this has been discussed elsewhere, but it's not >> clear from my reading of the "slots" proposal whether they would be allowed >> to target elements that are not direct children of the component. >> >> I believe the with the `select` attribute this was implicitly required >> because only compound selectors were supported (i.e. no child or descendent >> combinators) [1]. >> > > I think the actually issue is that you might have fights over who gets to > redistribute an element. Given > > <my-el-1> > <my-el-2> > <div content-slot="foo"></div> > </my-el-2> > </my-el-1> > > If both my-el-1 and my-el-2 have "foo" slots, who wins? What if the winner > by whatever rules adds a clashing slot name in a future update? > > I mentioned in this in Imperative API thread, but I think the least > surprising way forward for distributing non-children is to allow nodes to > cooperate on distribution, so a element could send its distributed nodes to > an ancestor: > https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0325.html > > > >> >> Would named slots be able to target elements farther down in the tree? >> > >> [1] >> http://w3c.github.io/webcomponents/spec/shadow/#dfn-content-element-select >> > >