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.

If you already knew that but still prefer content-slot attributes, then I guess 
we just disagree. But it wasn't clear.

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 
<<>> wrote:

On Mon, May 18, 2015 at 4:58 PM, Philip Walton 
<<>> 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



    <div content-slot="foo"></div>



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:

Would named slots be able to target elements farther down in the tree?


Reply via email to