W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2015

Re: [webcomponents] How about let's go with slots?

From: Domenic Denicola <d@domenic.me>
Date: Tue, 19 May 2015 01:13:05 +0000
To: "esprehn@chromium.org" <esprehn@chromium.org>, "justinfagnani@google.com" <justinfagnani@google.com>
CC: "philip@philipwalton.com" <philip@philipwalton.com>, "dfreedm@google.com" <dfreedm@google.com>, "dglazkov@google.com" <dglazkov@google.com>, "sjmiles@google.com" <sjmiles@google.com>, "rniwa@apple.com" <rniwa@apple.com>, "eoconnor@apple.com" <eoconnor@apple.com>, "annevk@annevk.nl" <annevk@annevk.nl>, "travis.leithead@microsoft.com" <travis.leithead@microsoft.com>, "mjs@apple.com" <mjs@apple.com>, "arronei@microsoft.com" <arronei@microsoft.com>, "slightlyoff@google.com" <slightlyoff@google.com>, "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <769DF95F72391C8C.1-1f6e9018-4017-42ec-98ff-de022e6ea6f7@mail.outlook.com>
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 <justinfagnani@google.com<mailto:justinfagnani@google.com>> wrote:

On Mon, May 18, 2015 at 4:58 PM, Philip Walton <philip@philipwalton.com<mailto: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
Received on Tuesday, 19 May 2015 01:13:36 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:31 UTC