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

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
<details>, 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.
<details> uses it, your fingers automatically used it before you
corrected your example, a number of Polymer examples use it, etc.
Requiring the use of "<header content-slot=header>" 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
<date-range-combo-box> illustrated by Daniel earlier in the thread
<https://gist.github.com/azakus/676590eb4d5b07b94428> 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

Received on Friday, 24 April 2015 21:22:09 UTC