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

  <div content-slot=“header”>
    Physics Department
    <content slot=“header”></content>

If an instance of this page then says


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:

    <div class=“header”>
      Physics Department
      <content select=“.header"></content>

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.


> 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

Reply via email to