Re: Proposal for changes to manage Shadow DOM content distribution

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. <jackalmage@gmail.com <mailto:jackalmage@gmail.com>> wrote:
>> 
>> On Wed, Apr 22, 2015 at 2:53 PM, Ryosuke Niwa <rniwa@apple.com <mailto:rniwa@apple.com>> wrote:
>>> On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. <jackalmage@gmail.com <mailto:jackalmage@gmail.com>> wrote:
>>>> On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa <rniwa@apple.com <mailto:rniwa@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. <jackalmage@gmail.com <mailto:jackalmage@gmail.com>> wrote:
>>>> On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa <rniwa@apple.com <mailto:rniwa@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
>