Re: Proposal for changes to manage Shadow DOM content distribution

[Ryosuke Niwa]

> On Apr 24, 2015, at 2:23 PM, Tab Atkins Jr.  wrote:
> 
> On Wed, Apr 22, 2015 at 5:04 PM, Ryosuke Niwa  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

[Tab Atkins Jr.]

On Wed, Apr 22, 2015 at 5:04 PM, Ryosuke Niwa  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

[Tab Atkins Jr.]

On Wed, Apr 22, 2015 at 4:40 PM, Jan Miksovsky  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):
>
> 
>   
> Physics Department
> 
>   
> 
>
> If an instance of this page then says
>
> 
>   Faculty
> 
>
> 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  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:
>
> 
>   
> 
>   Physics Department
>   
> 
>   
> 
>
> 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
, 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.
 uses it, your fingers automatically used it before you
corrected your example, a number of Polymer examples use it, etc.
Requiring the use of "" 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
 illustrated by Daniel earlier in the thread
 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

[Ryosuke Niwa]

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

>> 
>>   
>>   
>>   
>> 
> 
> 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
> 
>> 
>>   
>>   
>>   
>> 
> 
> 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:
>> 
>>   
>>   
>>   
>> 
> 
>  Which is more work for the CE author, but allows this for the user:
> 
>> 
>>   Title
>>   ...
>>   ...
>>   ...
>> 
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

[Justin Fagnani]

On Wed, Apr 22, 2015 at 4:40 PM, Jan Miksovsky 
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):
>
> 
>   
> Physics Department
> 
>   
> 
>
> If an instance of this page then says
>
> 
>   Faculty
> 
>

I know you mistakenly used a  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  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:
>
> 
>   
> 
>   Physics Department
>   
> 
>   
> 
>
> 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.  wrote:
>
> On Wed, Apr 22, 2015 at 2:53 PM, Ryosuke Niwa  wrote:
>
> On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr.  wrote:
>
> On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa  wrote:
>
> On Apr 22, 2015, at 8:52 AM, Domenic Denicola  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.
>
>
> 
>
>
> 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.  wrote:
>
> On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa  wrote:
>
> I don't think defining a slot based on an attribute value is something we'd
> like to sup

Re: Proposal for changes to manage Shadow DOM content distribution

[Ryosuke Niwa]

> On Apr 22, 2015, at 3:54 PM, Tab Atkins Jr.  wrote:
> 
> On Wed, Apr 22, 2015 at 2:53 PM, Ryosuke Niwa  wrote:
>> On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr.  wrote:
>>> On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa  wrote:
 On Apr 22, 2015, at 8:52 AM, Domenic Denicola  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.
>>> 
>>> 
>> 
>> 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 

[2] 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

[Jan Miksovsky]

Ugh, hit send too fast. In the university site example below, the instance 
should have been written:


  Faculty


–Jan

> On Apr 22, 2015, at 4:40 PM, Jan Miksovsky  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):
> 
> 
>   
> Physics Department
> 
>   
> 
> 
> If an instance of this page then says
> 
> 
>   Faculty
> 
> 
> 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  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:
> 
> 
>   
> 
>   Physics Department
>   
> 
>   
> 
> 
> 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. > > wrote:
>> 
>> On Wed, Apr 22, 2015 at 2:53 PM, Ryosuke Niwa > > wrote:
>>> On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. >> > wrote:
 On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa >>> > wrote:
> On Apr 22, 2015, at 8:52 AM, Domenic Denicola  > 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.
 
 
>>> 
>>> 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. >> > wrote:
 On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa >>> > 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 th

Re: Proposal for changes to manage Shadow DOM content distribution

[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
 
.
 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):


  
Physics Department

  


If an instance of this page then says


  Faculty


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  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:


  

  Physics Department
  

  


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.  wrote:
> 
> On Wed, Apr 22, 2015 at 2:53 PM, Ryosuke Niwa  wrote:
>> On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr.  wrote:
>>> On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa  wrote:
 On Apr 22, 2015, at 8:52 AM, Domenic Denicola  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.
>>> 
>>> 
>> 
>> 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.  wrote:
>>> On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa  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

[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 
mailto:justinfagn...@google.com>> wrote:



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

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




  

  

  


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




  

  

  


- R. Niwa

Re: Proposal for changes to manage Shadow DOM content distribution

[Olli Pettay]

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

On Wed, Apr 22, 2015 at 2:53 PM, Ryosuke Niwa  wrote:

On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr.  wrote:

On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa  wrote:

On Apr 22, 2015, at 8:52 AM, Domenic Denicola  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.





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%3Ainherits&find=&findi=&filter=^[^\0]*%24&hitlimit=&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

[Hayato Ito]

For the comparison, I've re-written the examples by using " 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
" as function" too.



On Wed, Apr 22, 2015 at 3:56 PM Dimitri Glazkov  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

[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<

Re: Proposal for changes to manage Shadow DOM content distribution

[Tab Atkins Jr.]

On Wed, Apr 22, 2015 at 2:53 PM, Ryosuke Niwa  wrote:
> On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr.  wrote:
>> On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa  wrote:
>>> On Apr 22, 2015, at 8:52 AM, Domenic Denicola  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.
>>
>> 
>
> 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.  wrote:
>> On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa  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

[Justin Fagnani]

On Wed, Apr 22, 2015 at 2:37 PM, Ryosuke Niwa  wrote:

>
> On Apr 22, 2015, at 10:16 AM, Justin Fagnani 
> wrote:
>
>
>
> On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa  wrote:
>
>>
>> > On Apr 21, 2015, at 10:23 PM, Justin Fagnani 
>> 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
>>  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:
>
> 
>   
>   
>   
> 
>
> 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
>
> 
>   
>   
>   
> 
>
> 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:


  
  
  


 Which is more work for the CE author, but allows this for the user:


  Title
  ...
  ...
  ...



Cheers,
  Justin


- R. Niwa
>
>

Re: Proposal for changes to manage Shadow DOM content distribution

[Ryosuke Niwa]

> On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr.  wrote:
> 
> On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa  wrote:
>>> On Apr 22, 2015, at 8:52 AM, Domenic Denicola  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.
> 
> 

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.  wrote:
> On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa  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 

[2] 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

[Tab Atkins Jr.]

On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa  wrote:
>> On Apr 22, 2015, at 8:52 AM, Domenic Denicola  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.



> 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

[Ryosuke Niwa]

> On Apr 22, 2015, at 10:16 AM, Justin Fagnani  wrote:
> 
> 
> 
> On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa  <mailto:rn...@apple.com>> wrote:
> 
> > On Apr 21, 2015, at 10:23 PM, Justin Fagnani  > <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  > 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:
> 
> 
>   
>   
>   
> 
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

> 
>   
>   
>   
> 
- R. Niwa

Re: Proposal for changes to manage Shadow DOM content distribution

[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  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  <mailto:justinfagn...@google.com>> wrote:
> 
> 
> On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa  <mailto:rn...@apple.com>> wrote:
> 
> > On Apr 21, 2015, at 10:23 PM, Justin Fagnani  > <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  > 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:
> 
> 
>   
>   
>   
> 
> Cheers,
>   Justin
>  
> 
> 
> - R. Niwa
> 
> 
> 

Re: Proposal for changes to manage Shadow DOM content distribution

[Ryosuke Niwa]

> On Apr 22, 2015, at 8:52 AM, Domenic Denicola  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

[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.  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
> > 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  > 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
> >>> >  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:
> >>
> >> 
> >>   
> >>   
> >>   
> >> 
> >>
> >> Cheers,
> >>   Justin
> >>
> >>>
> >>>
> >>>
> >>> - R. Niwa
> >>>
> >>
> >
>
>

Re: Proposal for changes to manage Shadow DOM content distribution

[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
 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 
> wrote:
>>
>>
>>
>> On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa  wrote:
>>>
>>>
>>> > On Apr 21, 2015, at 10:23 PM, Justin Fagnani 
>>> > 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
>>> >  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:
>>
>> 
>>   
>>   
>>   
>> 
>>
>> Cheers,
>>   Justin
>>
>>>
>>>
>>>
>>> - R. Niwa
>>>
>>
>

Re: Proposal for changes to manage Shadow DOM content distribution

[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 
wrote:

>
>
> On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa  wrote:
>
>>
>> > On Apr 21, 2015, at 10:23 PM, Justin Fagnani 
>> 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
>>  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:
>
> 
>   
>   
>   
> 
>
> Cheers,
>   Justin
>
>
>>
>>
>> - R. Niwa
>>
>>
>

Re: Proposal for changes to manage Shadow DOM content distribution

[Justin Fagnani]

On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa  wrote:

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


  
  
  


Cheers,
  Justin


>
>
> - R. Niwa
>
>

RE: Proposal for changes to manage Shadow DOM content distribution

[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

[Brian Kardell]

On Apr 21, 2015 10:29 PM, "Ryosuke Niwa"  wrote:
>
>
>> On Apr 21, 2015, at 10:17 PM, Brian Kardell  wrote:
>>
>> On Apr 21, 2015 8:22 PM, "Ryosuke Niwa"  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 . 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.
>
> 
>
> 
> 
>   
> 
>
> - 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

[Ryosuke Niwa]

> On Apr 21, 2015, at 11:08 PM, Domenic Denicola  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].
> 
>  is such an example, I think? Is the following a correct example of 
> what client code would have to look like for , under the proposal?
> 
> 
>  Stuff
>  
>More
>Stuff
>  
> 
> 
> or, if you wanted to avoid the wrapper div,
> 
> 
>  Stuff
>  More
>  Stuff
> 

This can just be 


 Stuff
 More
 Stuff


if our implementation had something along the line of:


  
  


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:


 Stuff
 More
 Stuff


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

[Ryosuke Niwa]

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

[Ryosuke Niwa]

> On Apr 21, 2015, at 10:17 PM, Brian Kardell  wrote:
> On Apr 21, 2015 8:22 PM, "Ryosuke Niwa"  <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 . 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.





  


- R. Niwa

Re: Proposal for changes to manage Shadow DOM content distribution

[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  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  wrote:

>
> On Apr 21, 2015, at 9:43 PM, Daniel Freedman  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  example that would take two date
> inputs (start date and end date) and distribute them through the example
> , 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  content elements, but 
> only takes inputs with slot "inputElement".
>
> How should this work?
>
> I drafted a quick gist to illustrate this:
> https://gist.github.com/azakus/676590eb4d5b07b94428
>
>
> 
> 
>   
>   
> 
>
> 
> 
>   
> 
>
>   
> 
> 
>   
> 
>   
> 
>
>
> 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:
>
> 
>   
> 
>   
> 
> 
>   
> 
>   
> 
>
>
> Here, the content elements are both creating slots and fulfilling slots.
>
> - R. Niwa
>
> On Tue, Apr 21, 2015 at 8:19 PM, Ryosuke Niwa  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

[Brian Kardell]

On Apr 21, 2015 8:22 PM, "Ryosuke Niwa"  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 . 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

[Ryosuke Niwa]

> On Apr 21, 2015, at 9:43 PM, Daniel Freedman  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  example that would take two date 
> inputs (start date and end date) and distribute them through the example 
> , 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  content elements, but  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>


  
  

 


  

   
  


  

  


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:


  

  


  

  


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

- R. Niwa

> On Tue, Apr 21, 2015 at 8:19 PM, Ryosuke Niwa  <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

[Dimitri Glazkov]

On Tue, Apr 21, 2015 at 9:43 PM, Daniel Freedman  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  example that would take two date
> inputs (start date and end date) and distribute them through the example
> , 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  content elements, but 
> 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

[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  example that would take two date
inputs (start date and end date) and distribute them through the example
, 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  content elements, but 
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  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
>
>

Proposal for changes to manage Shadow DOM content distribution

[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>