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

<physics-department-page>
  <span content-slot=“header">Faculty</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>
>   <header>Faculty</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.
>> 
>> 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
> 

Reply via email to