Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-25 Thread Ryosuke Niwa

 On Apr 24, 2015, at 2:23 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 
 On Wed, Apr 22, 2015 at 5:04 PM, Ryosuke Niwa rn...@apple.com wrote:
 I find it decidedly relevant given I'm pointing out that attribute-specified
 slots Domenic mentioned isn't what you described.  Since the only venue in
 which attribute-specified slots came up are [1], [2], and [3].  We're
 DEFINITELY NOT interested in filling slots based on values of arbitrary
 attributes.
 
 [1] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0188.html
 [2] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0190.html
 [3] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0195.html
 
 Apologies, I'd misread [1] and didn't realize it really was talking
 about projecting the value of an attribute into the content of a slot.
 
 (Though I'm confused by the vehemence of your denial here, given that
 in [2] you said you could imagine that such a feature could be easily
 added.)

What I meant is that we don't want a declarative syntax to filling a slot based 
with elements based on attribute values of those elements.  I'm less concerned 
about distributing the value of an attribute to a slot based on its attribute 
name.

Regardless, all of this is moot for foreseeable future given we just reached a 
consensus to focus on an imperative API for v1 on today's F2F.

- R. Niwa




Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-24 Thread Tab Atkins Jr.
On Wed, Apr 22, 2015 at 4:40 PM, Jan Miksovsky jan@component.kitchen wrote:
 Hi Tab,

 Thanks for your feedback!

 A primary motivation for proposing names instead of CSS selectors to control
 distribution is to enable subclassing. We think it’s important for a
 subclass to be able to override a base class insertion point. That seems
 easier to achieve with a name. It lets content insertion points behave like
 named DOM-valued component parameters that can be overridden by subclasses.

 To use an example, consider the page template component example at
 https://github.com/w3c/webcomponents/wiki/Shadow-DOM-Design-Constraints-In-Examples#page-templates.
 The image shows a page template for a large university web site. In this
 example, a base page template class defines a header slot. A university
 department wants to create a subclass of this template that partially
 populates some of the base class’ slots. In this case, it may want to add
 the department name to the header slot, then redefine an insertion point
 with the name that lets an individual page in that department add additional
 text to the header.

 The physics department page template subclass could then write something
 like this (following the proposal's syntax):

 template
   div content-slot=“header”
 Physics Department
 content slot=“header”/content
   /div
 template

 If an instance of this page then says

 physics-department-page
   headerFaculty/header
 /physics-department-page

 then the rendered result shows “Physics Department Faculty” in the base
 template header.

 This is analogous to what typical OOP languages enable when a subclass
 overrides a base class property. In such languages, the subclass simply
 defines a property with the same name as a base class property. The
 subclass’ property implementation can invoke the base class property
 implementation if it wants. The model is fairly easy to understand and
 implement, because the properties are always identified by name.

 A similar result could theoretically be achieved with CSS selectors, but the
 approach feels looser and a bit unwieldy, particularly if there are not
 rigid conventions about how the content select clauses are written.
 Assuming it were possible to reproject into a base class’ shadow — and
 that’s not actually possible today — you’d have to write something like:

 template
   shadow
 div class=“header”
   Physics Department
   content select=“.header/content
 /div
   /shadow
 /template

 So that approach could be made to work, but to me at least, feels harder,
 especially if the base class is using complex CSS selectors.

I'm not really seeing the complexity.  In particular, I'm not seeing
why content-slot/slot is easier than class/select.  For all simple
cases (class, attribute, tagname) it seems pretty much identical.
More complex selectors, like :nth-child(), might make it a bit more
difficult (as you have to match your markup to what the superclass is
expecting), but that's probably normally okay, and in problematic
cases is just because the superclass is being too clever.

On the other hand, requiring content-slot in order to place things in
anything but the default slot means you have to ugly up your markup
quite a bit.  It makes current UA-shadow-using elements, such as
details, impossible to duplicate, and makes all uses of shadow DOM
uglier and more verbose.

For example, I think tagname is a very common thing to select on.
details uses it, your fingers automatically used it before you
corrected your example, a number of Polymer examples use it, etc.
Requiring the use of header content-slot=header is adding 20
characters to the element.  A shadow-heavy page, such as some of the
Polymer examples, would have a relatively large amount of its page
weight being paid to this attribute scattered all over the place.

As Justin said, this seems to be extremely over-engineering towards
make subclass-and-reproject slightly more reliable, to the detriment
of every other case.  Subclass-and-reproject works just fine with
select='' unless the superclass's selector is too complex/specialized
to easily satisfy in your subclass's preferred markup; in the common
case of a tagname, class name, or attribute name, the two are
identical.

In return, content-slot makes the common case (just project into some
shadow) more verbose for the user, and make some cases, such as the
date-range-combo-box illustrated by Daniel earlier in the thread
https://gist.github.com/azakus/676590eb4d5b07b94428 impossible.

Overall, this feels like an over-optimization for implementation
complexity (matching content-slot to slot is easier than matching an
element to a selector) without fully considering the cost to the
author and user, which is a strong inversion of the priority of
constituencies.

~TJ



Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-24 Thread Tab Atkins Jr.
On Wed, Apr 22, 2015 at 5:04 PM, Ryosuke Niwa rn...@apple.com wrote:
 I find it decidedly relevant given I'm pointing out that attribute-specified
 slots Domenic mentioned isn't what you described.  Since the only venue in
 which attribute-specified slots came up are [1], [2], and [3].  We're
 DEFINITELY NOT interested in filling slots based on values of arbitrary
 attributes.

 [1] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0188.html
 [2] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0190.html
 [3] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0195.html

Apologies, I'd misread [1] and didn't realize it really was talking
about projecting the value of an attribute into the content of a slot.

(Though I'm confused by the vehemence of your denial here, given that
in [2] you said you could imagine that such a feature could be easily
added.)

~TJ



Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-22 Thread Brian Kardell
On Apr 21, 2015 10:29 PM, Ryosuke Niwa rn...@apple.com wrote:


 On Apr 21, 2015, at 10:17 PM, Brian Kardell bkard...@gmail.com wrote:

 On Apr 21, 2015 8:22 PM, Ryosuke Niwa rn...@apple.com wrote:
 
  Hi all,
 
  Following WebApps discussion last year [1] and earlier this year [2]
about template transclusions and inheritance in shadow DOM, Jan Miksovsky
at Component Kitchen, Ted O'Connor and I (Ryosuke Niwa) at Apple had
a meeting where we came up with changes to the way shadow DOM distributes
nodes to better fit real world use cases.
 
  After studying various real world use of web component APIs as well as
exiting GUI frameworks, we noticed that selector based node distribution as
currently spec'ed doesn't address common use cases and the extra
flexibility CSS selectors offers isn't needed in practice.  Instead, we
propose named insertion slots that could be filled with the contents in
the original DOM as well as contents in subclasses.  Because the proposal
uses the same slot filling mechanism for content distributions
and inheritance transclusions, it eliminates the need for multiple shadow
roots.
 
  Please take a look at our proposal at
https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution
 
  [1]
https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html
  [2]
https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0611.html
 

 I just wanted to note that a month or two I tried to assume nothing and
come up with a bare essentials concept which involved named slots.  Is
there a proposed a way to project from an attribute value into content or
from attribute to attribute..?

 In other words, if I had x-foo blah=hello . Can I map blah into a
slot or identify an attribute value in my template *as* a slot?

 Not at the moment but I could imagine that such a feature could be easily
added. e.g.

 x-foo blah=hello

 !-- implementation --
 template element=x-foo
   content attrslot=blah
 /template

 - R. Niwa


For the record, I'd love to see that discussed as part of a real proposal
because I think it's pretty useful - you can see lots of things essentially
trying to do custom elements in the wild with a similar need and it
honestly seems easier than element based slots technically speaking so it
would be a shame to lack it.


RE: Proposal for changes to manage Shadow DOM content distribution

2015-04-22 Thread Domenic Denicola
Between content-slot-specified slots, attribute-specified slots, element-named 
slots, and everything-else-slots, we're now in a weird place where we've 
reinvented a micro-language with some, but not all, of the power of CSS 
selectors. Is adding a new micro-language to the web platform worth helping 
implementers avoid the complexity of implementing CSS selector matching in this 
context?



Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-22 Thread Ryosuke Niwa

 On Apr 21, 2015, at 11:08 PM, Domenic Denicola d...@domenic.me wrote:
 
 From: Ryosuke Niwa [mailto:rn...@apple.com] 
 
 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].
 
 details is such an example, I think? Is the following a correct example of 
 what client code would have to look like for details, under the proposal?
 
 details
  div content-slot=summaryStuff/div
  div content-slot=main
pMore/p
pStuff/p
  /div
 /details
 
 or, if you wanted to avoid the wrapper div,
 
 details
  div content-slot=summaryStuff/div
  p content-slot=mainMore/p
  p content-slot=mainStuff/p
 /details

This can just be 

details
 div content-slot=summaryStuff/div
 pMore/p
 pStuff/p
/details

if our implementation had something along the line of:

template element=details
  content slot=summary/content
  content/content
/template

since we still support unnamed content element as the catch-all insertion point 
as it is today.

I'd rather not do it because it's rather confusing and arbitrary but if we 
really wanted to, it might be okay to allow element name as a slot-content 
name. e.g. the above example reduces to:

details
 summaryStuff/summary
 pMore/p
 pStuff/p
/details

That is, each element implicitly defines content-slot attribute with the value 
set to its element name.

- R. Niwa



Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-22 Thread Justin Fagnani
On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa rn...@apple.com wrote:


  On Apr 21, 2015, at 10:23 PM, Justin Fagnani 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.


 [1] See points 3 and 4 in
 https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec


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:

template
  content select=.header/content
  content select=:not(.footer)/content
  content select=.footer/content
/template

Cheers,
  Justin




 - R. Niwa




Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-22 Thread Justin Fagnani
Another technique I've seen used is compound selectors, which could be used
to migrate from one selector to another while preserving backwards
compatibility, or to provide some nice default distributions that are also
accessible via a class or attribute (ie, select=header, .header).

Could slots have multiple names to support something like this?

On Wed, Apr 22, 2015 at 10:16 AM, Justin Fagnani justinfagn...@google.com
wrote:



 On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa rn...@apple.com wrote:


  On Apr 21, 2015, at 10:23 PM, Justin Fagnani 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.


 [1] See points 3 and 4 in
 https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec


 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:

 template
   content select=.header/content
   content select=:not(.footer)/content
   content select=.footer/content
 /template

 Cheers,
   Justin




 - R. Niwa





Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-22 Thread Tab Atkins Jr.
This is literally reinventing Selectors at this point.  The solution
to we don't think it's worth implementing *all* of Selectors is to
define a subset of supported Selectors, not to define a brand new
mechanism that's equivalent to selectors but with a new syntax.

On Wed, Apr 22, 2015 at 10:21 AM, Justin Fagnani
justinfagn...@google.com wrote:
 Another technique I've seen used is compound selectors, which could be used
 to migrate from one selector to another while preserving backwards
 compatibility, or to provide some nice default distributions that are also
 accessible via a class or attribute (ie, select=header, .header).

 Could slots have multiple names to support something like this?

 On Wed, Apr 22, 2015 at 10:16 AM, Justin Fagnani justinfagn...@google.com
 wrote:



 On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa rn...@apple.com wrote:


  On Apr 21, 2015, at 10:23 PM, Justin Fagnani 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.


 [1] See points 3 and 4 in
 https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec


 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:

 template
   content select=.header/content
   content select=:not(.footer)/content
   content select=.footer/content
 /template

 Cheers,
   Justin




 - R. Niwa






Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-22 Thread Ryosuke Niwa

 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
   headerTitle/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



Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-22 Thread Ryosuke Niwa

 On Apr 22, 2015, at 3:54 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 
 On Wed, Apr 22, 2015 at 2:53 PM, Ryosuke Niwa rn...@apple.com wrote:
 On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa rn...@apple.com wrote:
 On Apr 22, 2015, at 8:52 AM, Domenic Denicola d...@domenic.me wrote:
 Between content-slot-specified slots, attribute-specified slots,
 element-named slots, and everything-else-slots, we're now in a weird place
 where we've reinvented a micro-language with some, but not all, of the 
 power
 of CSS selectors. Is adding a new micro-language to the web platform worth
 helping implementers avoid the complexity of implementing CSS selector
 matching in this context?
 
 I don't think mapping an attribute value to a slot is achievable with a
 content element with select attribute.
 
 content select=[my-attr='the slot value']
 
 No. That's not what I'm talking here.  I'm talking about putting the
 attribute value into the insertion point in [1] [2] [3], not distributing an
 element based on an attribute value.
 
 Oh, interesting.  That appears to be a complete non-sequitur, tho, as
 no one has asked for anything like that.  It's *certainly* irrelevant
 as a response to the text you quoted.

I find it decidedly relevant given I'm pointing out that attribute-specified 
slots Domenic mentioned isn't what you described.  Since the only venue in 
which attribute-specified slots came up are [1], [2], and [3].  We're 
DEFINITELY NOT interested in filling slots based on values of arbitrary 
attributes.

[1] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0188.html 
https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0188.html
[2] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0190.html 
https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0190.html
[3] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0195.html 
https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0195.html

- R. Niwa



Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-22 Thread Jan Miksovsky
Ugh, hit send too fast. In the university site example below, the instance 
should have been written:

physics-department-page
  span content-slot=“headerFaculty/span
/physics-department-page

–Jan

 On Apr 22, 2015, at 4:40 PM, Jan Miksovsky jan@component.kitchen wrote:
 
 Hi Tab,
 
 Thanks for your feedback!
 
 A primary motivation for proposing names instead of CSS selectors to control 
 distribution is to enable subclassing. We think it’s important for a subclass 
 to be able to override a base class insertion point. That seems easier to 
 achieve with a name. It lets content insertion points behave like named 
 DOM-valued component parameters that can be overridden by subclasses.
 
 To use an example, consider the page template component example at 
 https://github.com/w3c/webcomponents/wiki/Shadow-DOM-Design-Constraints-In-Examples#page-templates
  
 https://github.com/w3c/webcomponents/wiki/Shadow-DOM-Design-Constraints-In-Examples#page-templates.
  The image shows a page template for a large university web site. In this 
 example, a base page template class defines a header slot. A university 
 department wants to create a subclass of this template that partially 
 populates some of the base class’ slots. In this case, it may want to add the 
 department name to the header slot, then redefine an insertion point with the 
 name that lets an individual page in that department add additional text to 
 the header.
 
 The physics department page template subclass could then write something like 
 this (following the proposal's syntax):
 
 template
   div content-slot=“header”
 Physics Department
 content slot=“header”/content
   /div
 template
 
 If an instance of this page then says
 
 physics-department-page
   headerFaculty/header
 /physics-department-page
 
 then the rendered result shows “Physics Department Faculty” in the base 
 template header.
 
 This is analogous to what typical OOP languages enable when a subclass 
 overrides a base class property. In such languages, the subclass simply 
 defines a property with the same name as a base class property. The subclass’ 
 property implementation can invoke the base class property implementation if 
 it wants. The model is fairly easy to understand and implement, because the 
 properties are always identified by name.
 
 A similar result could theoretically be achieved with CSS selectors, but the 
 approach feels looser and a bit unwieldy, particularly if there are not rigid 
 conventions about how the content select clauses are written. Assuming it 
 were possible to reproject into a base class’ shadow — and that’s not 
 actually possible today — you’d have to write something like:
 
 template
   shadow
 div class=“header”
   Physics Department
   content select=“.header/content
 /div
   /shadow
 /template
 
 So that approach could be made to work, but to me at least, feels harder, 
 especially if the base class is using complex CSS selectors.
 
 –Jan
 
 On Apr 22, 2015, at 3:54 PM, Tab Atkins Jr. jackalm...@gmail.com 
 mailto:jackalm...@gmail.com wrote:
 
 On Wed, Apr 22, 2015 at 2:53 PM, Ryosuke Niwa rn...@apple.com 
 mailto:rn...@apple.com wrote:
 On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com 
 mailto:jackalm...@gmail.com wrote:
 On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa rn...@apple.com 
 mailto:rn...@apple.com wrote:
 On Apr 22, 2015, at 8:52 AM, Domenic Denicola d...@domenic.me 
 mailto:d...@domenic.me wrote:
 Between content-slot-specified slots, attribute-specified slots,
 element-named slots, and everything-else-slots, we're now in a weird 
 place
 where we've reinvented a micro-language with some, but not all, of the 
 power
 of CSS selectors. Is adding a new micro-language to the web platform 
 worth
 helping implementers avoid the complexity of implementing CSS selector
 matching in this context?
 
 I don't think mapping an attribute value to a slot is achievable with a
 content element with select attribute.
 
 content select=[my-attr='the slot value']
 
 No. That's not what I'm talking here.  I'm talking about putting the
 attribute value into the insertion point in [1] [2] [3], not distributing an
 element based on an attribute value.
 
 Oh, interesting.  That appears to be a complete non-sequitur, tho, as
 no one has asked for anything like that.  It's *certainly* irrelevant
 as a response to the text you quoted.
 
 On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com 
 mailto:jackalm...@gmail.com wrote:
 On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa rn...@apple.com 
 mailto:rn...@apple.com wrote:
 I don't think defining a slot based on an attribute value is something 
 we'd
 like to support.
 
 That is *literally* what your proposal already is, except limited to
 only paying attention to the value of the content-slot attribute.
 
 Distributing elements based on the value of a single well scoped attribute
 versus of an arbitrary attribute is A HUGE difference.
 
 

Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-22 Thread Justin Fagnani
On Wed, Apr 22, 2015 at 4:40 PM, Jan Miksovsky jan@component.kitchen
wrote:

 Hi Tab,

 Thanks for your feedback!

 A primary motivation for proposing names instead of CSS selectors to
 control distribution is to enable subclassing. We think it’s important for
 a subclass to be able to override a base class insertion point.


I understand this motivation and think it's a great point that hasn't (yet)
received enough attention...

But I think we would give up to much user ergonomics in exchange for it
under this proposal. I think we can relatively easily add the ability to
redirect nodes into distribution points of base classes to the existing
system which gives some control to authors on how to select nodes for
distribution.


 That seems easier to achieve with a name. It lets content insertion points
 behave like named DOM-valued component parameters that can be overridden by
 subclasses.

 To use an example, consider the page template component example at
 https://github.com/w3c/webcomponents/wiki/Shadow-DOM-Design-Constraints-In-Examples#page-templates.
 The image shows a page template for a large university web site. In this
 example, a base page template class defines a header slot. A university
 department wants to create a subclass of this template that partially
 populates some of the base class’ slots. In this case, it may want to add
 the department name to the header slot, then redefine an insertion point
 with the name that lets an individual page in that department add
 additional text to the header.

 The physics department page template subclass could then write something
 like this (following the proposal's syntax):

 template
   div content-slot=“header”
 Physics Department
 content slot=“header”/content
   /div
 template

 If an instance of this page then says

 physics-department-page
   headerFaculty/header
 /physics-department-page


I know you mistakenly used a header tag rather than content-slot here,
but I think it shows my point: this here (using header tags) might be the
better API, and I feel that the element author should be able to offer it
instead of forcing users to add content-slot attributes everywhere.

I think this proposal targets custom element subclassers at the expense of
custom element users. Yes, subclassers might need fine-grained control over
routing children and distributed nodes into base class distribution points.
But should end-users have to use the same API surface for that? For custom
elements to be successful we don't just need to appeal to element authors,
but in turn to their users.

Cheers,
  Justin


then the rendered result shows “Physics Department Faculty” in the base
 template header.

 This is analogous to what typical OOP languages enable when a subclass
 overrides a base class property. In such languages, the subclass simply
 defines a property with the same name as a base class property. The
 subclass’ property implementation can invoke the base class property
 implementation if it wants. The model is fairly easy to understand and
 implement, because the properties are always identified by name.

 A similar result could theoretically be achieved with CSS selectors, but
 the approach feels looser and a bit unwieldy, particularly if there are not
 rigid conventions about how the content select clauses are written.
 Assuming it were possible to reproject into a base class’ shadow — and
 that’s not actually possible today — you’d have to write something like:

 template
   shadow
 div class=“header”
   Physics Department
   content select=“.header/content
 /div
   /shadow
 /template

 So that approach could be made to work, but to me at least, feels harder,
 especially if the base class is using complex CSS selectors.

 –Jan

 On Apr 22, 2015, at 3:54 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:

 On Wed, Apr 22, 2015 at 2:53 PM, Ryosuke Niwa rn...@apple.com wrote:

 On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:

 On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa rn...@apple.com wrote:

 On Apr 22, 2015, at 8:52 AM, Domenic Denicola d...@domenic.me wrote:

 Between content-slot-specified slots, attribute-specified slots,
 element-named slots, and everything-else-slots, we're now in a weird place
 where we've reinvented a micro-language with some, but not all, of the
 power
 of CSS selectors. Is adding a new micro-language to the web platform worth
 helping implementers avoid the complexity of implementing CSS selector
 matching in this context?


 I don't think mapping an attribute value to a slot is achievable with a
 content element with select attribute.


 content select=[my-attr='the slot value']


 No. That's not what I'm talking here.  I'm talking about putting the
 attribute value into the insertion point in [1] [2] [3], not distributing
 an
 element based on an attribute value.


 Oh, interesting.  That appears to be a complete non-sequitur, tho, as
 no one has asked for anything like that.  

Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-22 Thread Tab Atkins Jr.
On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa rn...@apple.com wrote:
 On Apr 22, 2015, at 8:52 AM, Domenic Denicola d...@domenic.me wrote:
 Between content-slot-specified slots, attribute-specified slots, 
 element-named slots, and everything-else-slots, we're now in a weird place 
 where we've reinvented a micro-language with some, but not all, of the power 
 of CSS selectors. Is adding a new micro-language to the web platform worth 
 helping implementers avoid the complexity of implementing CSS selector 
 matching in this context?

 I don't think mapping an attribute value to a slot is achievable with a 
 content element with select attribute.

content select=[my-attr='the slot value']

 I don't think defining a slot based on an attribute value is something we'd 
 like to support.

That is *literally* what your proposal already is, except limited to
only paying attention to the value of the content-slot attribute.

~TJ



Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-22 Thread Olli Pettay

On 04/22/2015 03:54 PM, Tab Atkins Jr. wrote:

On Wed, Apr 22, 2015 at 2:53 PM, Ryosuke Niwa rn...@apple.com wrote:

On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:

On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa rn...@apple.com wrote:

On Apr 22, 2015, at 8:52 AM, Domenic Denicola d...@domenic.me wrote:

Between content-slot-specified slots, attribute-specified slots,
element-named slots, and everything-else-slots, we're now in a weird place
where we've reinvented a micro-language with some, but not all, of the power
of CSS selectors. Is adding a new micro-language to the web platform worth
helping implementers avoid the complexity of implementing CSS selector
matching in this context?


I don't think mapping an attribute value to a slot is achievable with a
content element with select attribute.


content select=[my-attr='the slot value']


No. That's not what I'm talking here.  I'm talking about putting the
attribute value into the insertion point in [1] [2] [3], not distributing an
element based on an attribute value.


Oh, interesting.  That appears to be a complete non-sequitur, tho, as
no one has asked for anything like that.  It's *certainly* irrelevant
as a response to the text you quoted.



FYI, putting attribute into the (attribute) insertion point is something 
XBL[1|2] support.
https://developer.mozilla.org/en-US/docs/XBL/XBL_1.0_Reference/Anonymous_Content#Attribute_Forwarding
http://www-archive.mozilla.org/projects/xbl/xbl2.html#forwarding

xbl:text isn't used too often, but used  anyhow,
http://mxr.mozilla.org/mozilla-central/search?string=xbl%3Atext
and xbl:inherits is rather common
http://mxr.mozilla.org/mozilla-central/search?string=xbl%3Ainheritsfind=findi=filter=^[^\0]*%24hitlimit=tree=mozilla-central
in Firefox' UI, which after all is mostly created using various components or 
bindings (doesn't matter whether the underlying language is XUL or HTML).



-Olli



Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-22 Thread Jan Miksovsky
Hi Tab,

Thanks for your feedback!

A primary motivation for proposing names instead of CSS selectors to control 
distribution is to enable subclassing. We think it’s important for a subclass 
to be able to override a base class insertion point. That seems easier to 
achieve with a name. It lets content insertion points behave like named 
DOM-valued component parameters that can be overridden by subclasses.

To use an example, consider the page template component example at 
https://github.com/w3c/webcomponents/wiki/Shadow-DOM-Design-Constraints-In-Examples#page-templates
 
https://github.com/w3c/webcomponents/wiki/Shadow-DOM-Design-Constraints-In-Examples#page-templates.
 The image shows a page template for a large university web site. In this 
example, a base page template class defines a header slot. A university 
department wants to create a subclass of this template that partially populates 
some of the base class’ slots. In this case, it may want to add the department 
name to the header slot, then redefine an insertion point with the name that 
lets an individual page in that department add additional text to the header.

The physics department page template subclass could then write something like 
this (following the proposal's syntax):

template
  div content-slot=“header”
Physics Department
content slot=“header”/content
  /div
template

If an instance of this page then says

physics-department-page
  headerFaculty/header
/physics-department-page

then the rendered result shows “Physics Department Faculty” in the base 
template header.

This is analogous to what typical OOP languages enable when a subclass 
overrides a base class property. In such languages, the subclass simply defines 
a property with the same name as a base class property. The subclass’ property 
implementation can invoke the base class property implementation if it wants. 
The model is fairly easy to understand and implement, because the properties 
are always identified by name.

A similar result could theoretically be achieved with CSS selectors, but the 
approach feels looser and a bit unwieldy, particularly if there are not rigid 
conventions about how the content select clauses are written. Assuming it 
were possible to reproject into a base class’ shadow — and that’s not actually 
possible today — you’d have to write something like:

template
  shadow
div class=“header”
  Physics Department
  content select=“.header/content
/div
  /shadow
/template

So that approach could be made to work, but to me at least, feels harder, 
especially if the base class is using complex CSS selectors.

–Jan

 On Apr 22, 2015, at 3:54 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 
 On Wed, Apr 22, 2015 at 2:53 PM, Ryosuke Niwa rn...@apple.com wrote:
 On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa rn...@apple.com wrote:
 On Apr 22, 2015, at 8:52 AM, Domenic Denicola d...@domenic.me wrote:
 Between content-slot-specified slots, attribute-specified slots,
 element-named slots, and everything-else-slots, we're now in a weird place
 where we've reinvented a micro-language with some, but not all, of the 
 power
 of CSS selectors. Is adding a new micro-language to the web platform worth
 helping implementers avoid the complexity of implementing CSS selector
 matching in this context?
 
 I don't think mapping an attribute value to a slot is achievable with a
 content element with select attribute.
 
 content select=[my-attr='the slot value']
 
 No. That's not what I'm talking here.  I'm talking about putting the
 attribute value into the insertion point in [1] [2] [3], not distributing an
 element based on an attribute value.
 
 Oh, interesting.  That appears to be a complete non-sequitur, tho, as
 no one has asked for anything like that.  It's *certainly* irrelevant
 as a response to the text you quoted.
 
 On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa rn...@apple.com wrote:
 I don't think defining a slot based on an attribute value is something we'd
 like to support.
 
 That is *literally* what your proposal already is, except limited to
 only paying attention to the value of the content-slot attribute.
 
 Distributing elements based on the value of a single well scoped attribute
 versus of an arbitrary attribute is A HUGE difference.
 
 Interesting.  Why?  And why do you think the difference is significant
 enough to justify such a limitation?  You seem to be okay with
 distributing elements based on the *name* of an arbitrary attribute;
 can you justify why that is so much better than using the value that
 you're willing to allow it, but not the other?
 
 ~TJ



Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-22 Thread Ryosuke Niwa

 On Apr 22, 2015, at 8:52 AM, Domenic Denicola d...@domenic.me wrote:
 
 Between content-slot-specified slots, attribute-specified slots, 
 element-named slots, and everything-else-slots, we're now in a weird place 
 where we've reinvented a micro-language with some, but not all, of the power 
 of CSS selectors. Is adding a new micro-language to the web platform worth 
 helping implementers avoid the complexity of implementing CSS selector 
 matching in this context?
 

I don't think mapping an attribute value to a slot is achievable with a content 
element with select attribute.

- R. Niwa




Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-22 Thread Hayato Ito
For the comparison, I've re-written the examples by using shadow as
function syntax.

https://gist.github.com/hayatoito/f2df8e10cb8cc551f80c

Can I assume that both have the same power, fundamentally?
(Please ignore that power of the CSS selector here ;)

If both approaches have the (almost) equivalent power, I guess the
technical difficulties to implement these features don't differ so much.
If we could implement the new proposal, I think we could implement
shadow as function too.



On Wed, Apr 22, 2015 at 3:56 PM Dimitri Glazkov dglaz...@google.com wrote:

 FWIW, I can see the appeal of a slot-based approach in Ryosuke/Ted/Jan
 proposal.

 It reduces the implementation complexity: all of the selector-checking
 logic in
 http://w3c.github.io/webcomponents/spec/shadow/#satisfying-matching-criteria
 is replaced with (what effectively is) a map lookup.

 While some loss of flexibility is a cost, I think it's worth considering
 this trade-off, especially if it is a sticking point for implementers who
 are looking to reduce the overall cost of Shadow DOM implementation.

 In fact, if we reach cross-vendor agreement and decide to go with the
 slot-based approach, we probably should avoid adding extra sugar around
 element names and attribute values as slot indicators, and instead double
 down on developing a good imperative API that overcomes the loss of
 flexibility.

 :DG



Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-22 Thread Ryosuke Niwa

 On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 
 On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa rn...@apple.com wrote:
 On Apr 22, 2015, at 8:52 AM, Domenic Denicola d...@domenic.me wrote:
 Between content-slot-specified slots, attribute-specified slots, 
 element-named slots, and everything-else-slots, we're now in a weird place 
 where we've reinvented a micro-language with some, but not all, of the 
 power of CSS selectors. Is adding a new micro-language to the web platform 
 worth helping implementers avoid the complexity of implementing CSS 
 selector matching in this context?
 
 I don't think mapping an attribute value to a slot is achievable with a 
 content element with select attribute.
 
 content select=[my-attr='the slot value']

No. That's not what I'm talking here.  I'm talking about putting the attribute 
value into the insertion point in [1] [2] [3], not distributing an element 
based on an attribute value.

 On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa rn...@apple.com wrote:
 I don't think defining a slot based on an attribute value is something we'd 
 like to support.
 
 That is *literally* what your proposal already is, except limited to
 only paying attention to the value of the content-slot attribute.


Distributing elements based on the value of a single well scoped attribute 
versus of an arbitrary attribute is A HUGE difference.

[1] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0188.html 
https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0188.html
[2] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0190.html 
https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0190.html
[3] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0195.html

- R. Niwa



Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-22 Thread Justin Fagnani
On Wed, Apr 22, 2015 at 2:37 PM, Ryosuke Niwa rn...@apple.com wrote:


 On Apr 22, 2015, at 10:16 AM, Justin Fagnani justinfagn...@google.com
 wrote:



 On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa rn...@apple.com wrote:


  On Apr 21, 2015, at 10:23 PM, Justin Fagnani 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.




 [1] See points 3 and 4 in
 https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec


 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:

 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
  headerTitle/header
  p.../p
  p.../p
  footer.../footer
/my-element


Cheers,
  Justin


- R. Niwa




Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-22 Thread Ryosuke Niwa
I don't think defining a slot based on an attribute value is something we'd 
like to support.

 On Apr 22, 2015, at 10:21 AM, Justin Fagnani justinfagn...@google.com wrote:
 
 Another technique I've seen used is compound selectors, which could be used 
 to migrate from one selector to another while preserving backwards 
 compatibility, or to provide some nice default distributions that are also 
 accessible via a class or attribute (ie, select=header, .header).
 
 Could slots have multiple names to support something like this?
 
 On Wed, 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.
 
 [1] See points 3 and 4 in 
 https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec
  
 https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec
 
 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:
 
 template
   content select=.header/content
   content select=:not(.footer)/content
   content select=.footer/content
 /template
 Cheers,
   Justin
  
 
 
 - R. Niwa
 
 
 



RE: Proposal for changes to manage Shadow DOM content distribution

2015-04-22 Thread Travis Leithead
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.commailto:justinfagn...@google.com wrote:



On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa 
rn...@apple.commailto:rn...@apple.com wrote:

 On Apr 21, 2015, at 10:23 PM, Justin Fagnani 
 justinfagn...@google.commailto: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?

[1] See points 3 and 4 in 
https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec

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:


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
- R. Niwa



Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-22 Thread Ryosuke Niwa

 On Apr 22, 2015, at 10:16 AM, Justin Fagnani 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?

 [1] See points 3 and 4 in 
 https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec
  
 https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec
 
 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:
 
 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
- R. Niwa



Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-22 Thread Erik Bryn
FWIW, we're working to implement what we call named blocks in Ember.js and
believe this proposal aligns very closely to what our users have been
asking us to build for them.

- Erik

On Wednesday, April 22, 2015, Tab Atkins Jr. jackalm...@gmail.com wrote:

 This is literally reinventing Selectors at this point.  The solution
 to we don't think it's worth implementing *all* of Selectors is to
 define a subset of supported Selectors, not to define a brand new
 mechanism that's equivalent to selectors but with a new syntax.

 On Wed, Apr 22, 2015 at 10:21 AM, Justin Fagnani
 justinfagn...@google.com javascript:; wrote:
  Another technique I've seen used is compound selectors, which could be
 used
  to migrate from one selector to another while preserving backwards
  compatibility, or to provide some nice default distributions that are
 also
  accessible via a class or attribute (ie, select=header, .header).
 
  Could slots have multiple names to support something like this?
 
  On Wed, Apr 22, 2015 at 10:16 AM, Justin Fagnani 
 justinfagn...@google.com javascript:;
  wrote:
 
 
 
  On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa rn...@apple.com
 javascript:; wrote:
 
 
   On Apr 21, 2015, at 10:23 PM, Justin Fagnani 
 justinfagn...@google.com javascript:;
   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.
 
 
  [1] See points 3 and 4 in
 
 https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec
 
 
  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:
 
  template
content select=.header/content
content select=:not(.footer)/content
content select=.footer/content
  /template
 
  Cheers,
Justin
 
 
 
 
  - R. Niwa
 
 
 




Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-22 Thread Tab Atkins Jr.
On Wed, Apr 22, 2015 at 2:53 PM, Ryosuke Niwa rn...@apple.com wrote:
 On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa rn...@apple.com wrote:
 On Apr 22, 2015, at 8:52 AM, Domenic Denicola d...@domenic.me wrote:
 Between content-slot-specified slots, attribute-specified slots,
 element-named slots, and everything-else-slots, we're now in a weird place
 where we've reinvented a micro-language with some, but not all, of the 
 power
 of CSS selectors. Is adding a new micro-language to the web platform worth
 helping implementers avoid the complexity of implementing CSS selector
 matching in this context?

 I don't think mapping an attribute value to a slot is achievable with a
 content element with select attribute.

 content select=[my-attr='the slot value']

 No. That's not what I'm talking here.  I'm talking about putting the
 attribute value into the insertion point in [1] [2] [3], not distributing an
 element based on an attribute value.

Oh, interesting.  That appears to be a complete non-sequitur, tho, as
no one has asked for anything like that.  It's *certainly* irrelevant
as a response to the text you quoted.

 On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa rn...@apple.com wrote:
 I don't think defining a slot based on an attribute value is something we'd
 like to support.

 That is *literally* what your proposal already is, except limited to
 only paying attention to the value of the content-slot attribute.

 Distributing elements based on the value of a single well scoped attribute
 versus of an arbitrary attribute is A HUGE difference.

Interesting.  Why?  And why do you think the difference is significant
enough to justify such a limitation?  You seem to be okay with
distributing elements based on the *name* of an arbitrary attribute;
can you justify why that is so much better than using the value that
you're willing to allow it, but not the other?

~TJ



Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-22 Thread Dimitri Glazkov
FWIW, I can see the appeal of a slot-based approach in Ryosuke/Ted/Jan
proposal.

It reduces the implementation complexity: all of the selector-checking
logic in
http://w3c.github.io/webcomponents/spec/shadow/#satisfying-matching-criteria
is replaced with (what effectively is) a map lookup.

While some loss of flexibility is a cost, I think it's worth considering
this trade-off, especially if it is a sticking point for implementers who
are looking to reduce the overall cost of Shadow DOM implementation.

In fact, if we reach cross-vendor agreement and decide to go with the
slot-based approach, we probably should avoid adding extra sugar around
element names and attribute values as slot indicators, and instead double
down on developing a good imperative API that overcomes the loss of
flexibility.

:DG


Proposal for changes to manage Shadow DOM content distribution

2015-04-21 Thread Ryosuke Niwa
Hi all,

Following WebApps discussion last year [1] and earlier this year [2] about 
template transclusions and inheritance in shadow DOM, Jan Miksovsky at 
Component Kitchen, Ted O'Connor and I (Ryosuke Niwa) at Apple had a meeting 
where we came up with changes to the way shadow DOM distributes nodes to better 
fit real world use cases.

After studying various real world use of web component APIs as well as exiting 
GUI frameworks, we noticed that selector based node distribution as currently 
spec'ed doesn't address common use cases and the extra flexibility CSS 
selectors offers isn't needed in practice.  Instead, we propose named insertion 
slots that could be filled with the contents in the original DOM as well as 
contents in subclasses.  Because the proposal uses the same slot filling 
mechanism for content distributions and inheritance transclusions, it 
eliminates the need for multiple shadow roots.

Please take a look at our proposal at 
https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution
 
https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution

[1] https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html 
https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html
[2] https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0611.html 
https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0611.html



Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-21 Thread Dimitri Glazkov
On Tue, Apr 21, 2015 at 9:43 PM, Daniel Freedman dfre...@google.com wrote:

 Hi Ryosuke,

 I want to start by thanking you, Ted, and Jan for taking the time to make
 this proposal.

 I read through the proposal, and had a quick question about how
 redistribution should work with this slot concept.
 I created a quick date-range-combo-box example that would take two date
 inputs (start date and end date) and distribute them through the example
 date-combo-box, but I found myself stuck.
 I can't name the two date inputs with the same slot or they will end up in
 only one of the date-combo-box content elements, but date-combo-box
 only takes inputs with slot inputElement.

 How should this work?

 I drafted a quick gist to illustrate this:
 https://gist.github.com/azakus/676590eb4d5b07b94428


Maybe there could be something like a simple routing scheme for these cases?
https://gist.github.com/dglazkov/7d6acd4c205a58054a7c

:DG


Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-21 Thread Brian Kardell
On Apr 21, 2015 8:22 PM, Ryosuke Niwa rn...@apple.com wrote:

 Hi all,

 Following WebApps discussion last year [1] and earlier this year [2]
about template transclusions and inheritance in shadow DOM, Jan Miksovsky
at Component Kitchen, Ted O'Connor and I (Ryosuke Niwa) at Apple had
a meeting where we came up with changes to the way shadow DOM distributes
nodes to better fit real world use cases.

 After studying various real world use of web component APIs as well as
exiting GUI frameworks, we noticed that selector based node distribution as
currently spec'ed doesn't address common use cases and the extra
flexibility CSS selectors offers isn't needed in practice.  Instead, we
propose named insertion slots that could be filled with the contents in
the original DOM as well as contents in subclasses.  Because the proposal
uses the same slot filling mechanism for content distributions
and inheritance transclusions, it eliminates the need for multiple shadow
roots.

 Please take a look at our proposal at
https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution

 [1]
https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html
 [2]
https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0611.html


I just wanted to note that a month or two I tried to assume nothing and
come up with a bare essentials concept which involved named slots.  Is
there a proposed a way to project from an attribute value into content or
from attribute to attribute..?

In other words, if I had x-foo blah=hello . Can I map blah into a slot
or identify an attribute value in my template *as* a slot?


Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-21 Thread Ryosuke Niwa

 On Apr 21, 2015, at 10:17 PM, Brian Kardell bkard...@gmail.com wrote:
 On Apr 21, 2015 8:22 PM, Ryosuke Niwa rn...@apple.com 
 mailto:rn...@apple.com wrote:
 
  Hi all,
 
  Following WebApps discussion last year [1] and earlier this year [2] about 
  template transclusions and inheritance in shadow DOM, Jan Miksovsky at 
  Component Kitchen, Ted O'Connor and I (Ryosuke Niwa) at Apple had a meeting 
  where we came up with changes to the way shadow DOM distributes nodes to 
  better fit real world use cases.
 
  After studying various real world use of web component APIs as well as 
  exiting GUI frameworks, we noticed that selector based node distribution as 
  currently spec'ed doesn't address common use cases and the extra 
  flexibility CSS selectors offers isn't needed in practice.  Instead, we 
  propose named insertion slots that could be filled with the contents in 
  the original DOM as well as contents in subclasses.  Because the proposal 
  uses the same slot filling mechanism for content distributions and 
  inheritance transclusions, it eliminates the need for multiple shadow roots.
 
  Please take a look at our proposal at 
  https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution
   
  https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution
 
  [1] 
  https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html 
  https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html
  [2] 
  https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0611.html 
  https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0611.html
 
 
 I just wanted to note that a month or two I tried to assume nothing and come 
 up with a bare essentials concept which involved named slots.  Is there a 
 proposed a way to project from an attribute value into content or from 
 attribute to attribute..?
 
 In other words, if I had x-foo blah=hello . Can I map blah into a slot or 
 identify an attribute value in my template *as* a slot?
 

Not at the moment but I could imagine that such a feature could be easily 
added. e.g.

x-foo blah=hello

!-- implementation --
template element=x-foo
  content attrslot=blah
/template

- R. Niwa



Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-21 Thread Ryosuke Niwa

 On Apr 21, 2015, at 9:43 PM, Daniel Freedman dfre...@google.com wrote:
 
 Hi Ryosuke,
 
 I want to start by thanking you, Ted, and Jan for taking the time to make 
 this proposal.
 
 I read through the proposal, and had a quick question about how 
 redistribution should work with this slot concept.
 I created a quick date-range-combo-box example that would take two date 
 inputs (start date and end date) and distribute them through the example 
 date-combo-box, but I found myself stuck.
 I can't name the two date inputs with the same slot or they will end up in 
 only one of the date-combo-box content elements, but date-combo-box only 
 takes inputs with slot inputElement.
 
 How should this work?
 
 I drafted a quick gist to illustrate this: 
 https://gist.github.com/azakus/676590eb4d5b07b94428 
 https://gist.github.com/azakus/676590eb4d5b07b94428
!-- instance --
date-range-combo-box
  input type=date content-slot=start!-- (1) --
  input type=date content-slot=end!-- (2) --
/date-range-combo-box
 
!— implementation of date-range-combo-box --
template
  shadow
date-combo-box!-- (3) --
   !--
   How can input[content-slot=start] end up in the content 
slot=inputElement
   in the date-combo-box ?
   --
  content slot=start/content
/date-combo-box
date-combo-box!-- (4) --
  content slot=end/content
/date-combo-box
  /shadow
/template

Am I right in assuming that you want to re-distribute (1) into (3)'s and (2) 
into (4)'s inputElements?  If so, I'd imagine one possible syntax is as follows:

template
  shadow
date-combo-box!-- (3) --
  content slot=start content-slot=inputElement/content
/date-combo-box
date-combo-box!-- (4) --
  content slot=end content-slot=inputElement/content
/date-combo-box
  /shadow
/template

Here, the content elements are both creating slots and fulfilling slots.

- R. Niwa

 On Tue, Apr 21, 2015 at 8:19 PM, Ryosuke Niwa rn...@apple.com 
 mailto:rn...@apple.com wrote:
 Hi all,
 
 Following WebApps discussion last year [1] and earlier this year [2] about 
 template transclusions and inheritance in shadow DOM, Jan Miksovsky at 
 Component Kitchen, Ted O'Connor and I (Ryosuke Niwa) at Apple had a meeting 
 where we came up with changes to the way shadow DOM distributes nodes to 
 better fit real world use cases.
 
 After studying various real world use of web component APIs as well as 
 exiting GUI frameworks, we noticed that selector based node distribution as 
 currently spec'ed doesn't address common use cases and the extra flexibility 
 CSS selectors offers isn't needed in practice.  Instead, we propose named 
 insertion slots that could be filled with the contents in the original DOM 
 as well as contents in subclasses.  Because the proposal uses the same slot 
 filling mechanism for content distributions and inheritance transclusions, it 
 eliminates the need for multiple shadow roots.
 
 Please take a look at our proposal at 
 https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution
  
 https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution
 
 [1] https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html 
 https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html
 [2] https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0611.html 
 https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0611.html
 
 



Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-21 Thread Ryosuke Niwa

 On Apr 21, 2015, at 10:23 PM, Justin Fagnani 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].

[1] See points 3 and 4 in 
https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec

- R. Niwa




Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-21 Thread Daniel Freedman
Hi Ryosuke,

I want to start by thanking you, Ted, and Jan for taking the time to make
this proposal.

I read through the proposal, and had a quick question about how
redistribution should work with this slot concept.
I created a quick date-range-combo-box example that would take two date
inputs (start date and end date) and distribute them through the example
date-combo-box, but I found myself stuck.
I can't name the two date inputs with the same slot or they will end up in
only one of the date-combo-box content elements, but date-combo-box
only takes inputs with slot inputElement.

How should this work?

I drafted a quick gist to illustrate this:
https://gist.github.com/azakus/676590eb4d5b07b94428

Thanks!

On Tue, Apr 21, 2015 at 8:19 PM, Ryosuke Niwa rn...@apple.com wrote:

 Hi all,

 Following WebApps discussion last year [1] and earlier this year [2] about
 template transclusions and inheritance in shadow DOM, Jan Miksovsky at
 Component Kitchen, Ted O'Connor and I (Ryosuke Niwa) at Apple had
 a meeting where we came up with changes to the way shadow DOM distributes
 nodes to better fit real world use cases.

 After studying various real world use of web component APIs as well as
 exiting GUI frameworks, we noticed that selector based node distribution as
 currently spec'ed doesn't address common use cases and the extra
 flexibility CSS selectors offers isn't needed in practice.  Instead, we
 propose named insertion slots that could be filled with the contents in
 the original DOM as well as contents in subclasses.  Because the proposal
 uses the same slot filling mechanism for content distributions and
 inheritance transclusions, it eliminates the need for multiple shadow
 roots.

 Please take a look at our proposal at
 https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution

 [1]
 https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html
 [2]
 https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0611.html




Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-21 Thread Justin Fagnani
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?

Cheers,
  Justin


On Tue, Apr 21, 2015 at 9:57 PM, Ryosuke Niwa rn...@apple.com wrote:


 On Apr 21, 2015, at 9:43 PM, Daniel Freedman dfre...@google.com wrote:

 Hi Ryosuke,

 I want to start by thanking you, Ted, and Jan for taking the time to make
 this proposal.

 I read through the proposal, and had a quick question about how
 redistribution should work with this slot concept.
 I created a quick date-range-combo-box example that would take two date
 inputs (start date and end date) and distribute them through the example
 date-combo-box, but I found myself stuck.
 I can't name the two date inputs with the same slot or they will end up in
 only one of the date-combo-box content elements, but date-combo-box
 only takes inputs with slot inputElement.

 How should this work?

 I drafted a quick gist to illustrate this:
 https://gist.github.com/azakus/676590eb4d5b07b94428


 !-- instance --
 date-range-combo-box
   input type=date content-slot=start!-- (1) --
   input type=date content-slot=end!-- (2) --
 /date-range-combo-box

 !— implementation of date-range-combo-box --
 template
   shadow
 date-combo-box!-- (3) --
!--
How can input[content-slot=start] end up in the content 
 slot=inputElement
in the date-combo-box ?
--
   content slot=start/content
 /date-combo-box
 date-combo-box!-- (4) --
   content slot=end/content
 /date-combo-box
   /shadow
 /template


 Am I right in assuming that you want to re-distribute (1) into (3)'s and
 (2) into (4)'s inputElements?  If so, I'd imagine one possible syntax is as
 follows:

 template
   shadow
 date-combo-box!-- (3) --
   content slot=start content-slot=inputElement/content
 /date-combo-box
 date-combo-box!-- (4) --
   content slot=end content-slot=inputElement/content
 /date-combo-box
   /shadow
 /template


 Here, the content elements are both creating slots and fulfilling slots.

 - R. Niwa

 On Tue, Apr 21, 2015 at 8:19 PM, Ryosuke Niwa rn...@apple.com wrote:

 Hi all,

 Following WebApps discussion last year [1] and earlier this year [2]
 about template transclusions and inheritance in shadow DOM, Jan Miksovsky
 at Component Kitchen, Ted O'Connor and I (Ryosuke Niwa) at Apple had
 a meeting where we came up with changes to the way shadow DOM distributes
 nodes to better fit real world use cases.

 After studying various real world use of web component APIs as well as
 exiting GUI frameworks, we noticed that selector based node distribution as
 currently spec'ed doesn't address common use cases and the extra
 flexibility CSS selectors offers isn't needed in practice.  Instead, we
 propose named insertion slots that could be filled with the contents in
 the original DOM as well as contents in subclasses.  Because the proposal
 uses the same slot filling mechanism for content distributions and
 inheritance transclusions, it eliminates the need for multiple shadow
 roots.

 Please take a look at our proposal at
 https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution

 [1]
 https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html
 [2]
 https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0611.html