On Mon, May 18, 2015 at 6:13 PM, Domenic Denicola <d@domenic.me> wrote:
> In case it wasn't clear, named slots vs. tag names is purely a bikeshed
> color (but an important one, in the "syntax is UI" sense). None of the
> details of how the proposal works change at all.
>
They're not equivalent, because any element can have the right content-slot
value, but with tag names, only one (or maybe N) names would be supported.
> If you already knew that but still prefer content-slot attributes, then I
> guess we just disagree. But it wasn't clear.
>
I greatly prefer select, but this is a compromise to enable progress.
>
> From: Elliott Sprehn
> Sent: Monday, May 18, 21:03
> Subject: Re: [webcomponents] How about let's go with slots?
> To: Justin Fagnani
> Cc: Philip Walton, Domenic Denicola, Daniel Freedman, Dimitri Glazkov,
> Scott Miles, Ryosuke Niwa, Edward O'Connor, Anne van Kesteren, Travis
> Leithead, Maciej Stachowiak, Arron Eicholz, Alex Russell, public-webapps
>
> 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 <justinfagnani@google.com>
> wrote:
>
> On Mon, May 18, 2015 at 4:58 PM, Philip Walton <philip@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
>
>
>
>
>