> On Apr 22, 2015, at 3:48 PM, Justin Fagnani <justinfagn...@google.com> wrote:
> On Wed, Apr 22, 2015 at 2:37 PM, Ryosuke Niwa <rn...@apple.com 
> <mailto:rn...@apple.com>> wrote:
>> On Apr 22, 2015, at 10:16 AM, Justin Fagnani <justinfagn...@google.com 
>> <mailto:justinfagn...@google.com>> wrote:
>> On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa <rn...@apple.com 
>> <mailto:rn...@apple.com>> wrote:
>> > On Apr 21, 2015, at 10:23 PM, Justin Fagnani <justinfagn...@google.com 
>> > <mailto:justinfagn...@google.com>> wrote:
>> >
>> > I do want the ability to redirect distributed nodes into a holes in the 
>> > base template, so that part is welcome to me. However, my first reaction 
>> > to the slot idea is that forcing users to add the content-slot attribute 
>> > on children significantly impairs the DOM API surface area of custom 
>> > elements.
>> >
>> > For the single-level distribution case, how is this different from 
>> > <content select="[content-slot=name]"> except that content select can 
>> > distribute based on features of the children that might already exist, 
>> > like tag names or an attribute?
>> At the conceptual level, they're equivalent.  However, we didn't find the 
>> extra flexibility of using CSS selectors compelling as we mentioned in our 
>> proposal [1].
>> I personally would like to see more power, especially positional selectors. 
>> Some components would be better off selecting their first child, rather than 
>> requiring a class.
> What are concrete use cases that require such flexibility?
> Require is a strong word :) but the case I recently experienced was a panel 
> with a header. It always expects one child for the header and the rest for 
> content. There are several ways to do this, and one would be to select the 
> first child into one distribution point and the rest into another. Another 
> way is to use attributes, classes or a specific set of tag names. The key for 
> me here is that you give the custom element author a choice on how to shape 
> their API.

I don't think letting authors of each component choose how to select nodes of 
distributions will increase the inconsistencies between components written by 
different authors and deteriorate the ergonomics of component users.

>> <template>
>>   <content select=".header"></content>
>>   <content select=":not(.footer)"></content>
>>   <content select=".footer"></content>
>> </template>
> Our point wasn't so much that it's not achievable.  With enough hackeries and 
> "techniques", we can.  The problem is the developer ergonomics of content 
> element with select attribute with common real world use cases.  For example, 
> the above code is a lot more verbose and less intuitive than
>> <template>
>>   <content slot="header"></content>
>>   <content></content>
>>   <content slot="footer"></content>
>> </template>
> This is true, but it's a trade off for custom element authoring brevity vs 
> custom element use brevity (and authoring expressiveness). I'd personally 
> rather optimize for custom element user ergonomics, and give custom element 
> authors the power to make their elements easy and convenient.
> Continuing this example I would actually make the selectors more complex 
> because we have these nice semantic elements in html5:
>> <template>
>>   <content select="header, .header"></content>
>>   <content select=":not(footer, .footer)"></content>
>>   <content select="footer, .footer"></content>
>> </template>
>  Which is more work for the CE author, but allows this for the user:
>> <my-element>
>>   <header>Title</header>
>>   <p>...</p>
>>   <p>...</p>
>>   <footer>...</footer>
>> </my-element>
That's a fair point but it is a feature that the user of components needs to 
explicitly opt-in to use slot-content.  That explicit contract ensures the API 
surface to be limited.  Suppose in the version 1 of this component, it only 
supported "header".  If the version 2 of this component subsequently added the 
support for "footer", it's unclear whether every existing use of "footer" 
element is appropriate for node distribution.  This poses a serious challenge 
for adding new features to your components.  In addition, such an explicit 
contract is a must-have requirement for cross-origin components we (Apple's 
WebKit team) have been advocating for years now.

- R. Niwa

Reply via email to