Re: Proposal for changes to manage Shadow DOM content distribution

> On Apr 22, 2015, at 3:48 PM, Justin Fagnani <justinfagnani@google.com> wrote:
> 
> On Wed, Apr 22, 2015 at 2:37 PM, Ryosuke Niwa <rniwa@apple.com <mailto:rniwa@apple.com>> wrote:
> 
>> On Apr 22, 2015, at 10:16 AM, Justin Fagnani <justinfagnani@google.com <mailto:justinfagnani@google.com>> wrote:
>> 
>> On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa <rniwa@apple.com <mailto:rniwa@apple.com>> wrote:
>> 
>> > On Apr 21, 2015, at 10:23 PM, Justin Fagnani <justinfagnani@google.com <mailto:justinfagnani@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