Re: Proposal for changes to manage Shadow DOM content distribution

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