I like that the light-side DOM elements must opt-in to being redistributed. 
While appearing at first like a hindrance, it does ensure that elements can't 
be arbitrarily re-distributed without their consent. If you imagine allowing 
redistribution into a cross-origin shadow dom, then it becomes somewhat more 
important to be a bit more cautious (or at least declarative). I like the 
cooperative symmetry.

I also like the idea of being able to drop the multiple shadow trees 
requirement. Can this still be accomplished if select="" is not used? I'm still 
grokking the details...

From: Ryosuke Niwa [mailto:rn...@apple.com]
Sent: Wednesday, April 22, 2015 2:37 PM
To: Justin Fagnani
Cc: Daniel Freedman; WebApps WG; Edward O'Connor; Jan Miksovsky
Subject: Re: Proposal for changes to manage Shadow DOM content distribution

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 

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?

[1] See points 3 and 4 in 

Point 4 is interesting, because unless I'm missing something (which could be!) 
it's incorrect. You can create selectors with :not() that exclude the content 
selectors that come after in document order. I would rewrite the example as:


  <content select=".header"></content>

  <content select=":not(.footer)"></content>

  <content select=".footer"></content>

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


  <content slot="header"></content>


  <content slot="footer"></content>

- R. Niwa

Reply via email to