Re: Inheritance Model for Shadow DOM Revisited

Thanks. As far as my understanding is correct, the conclusions so far are:

- There is no use cases which "<shadow> as function" can't support, but
"<content slot>" can support.
- there are use cases which "<shadow> as function" can support, but
"<content slot>" can't support.
- "<shadow> as function" is more expressive than "<content slot>"
- "<content slot>" is trying to achieve something by removing
expressiveness from web developers, instead of trusting them.

I still don't understand fully what the proposal is trying to achieve. I've
never heard such a complain, "<content select> is too expressive and easy
to be misused. Please remove it", from web developers.

I think any good APIs could be potentially wrongly used by a web developer.
But that shouldn't be a reason that we can remove a expressive API from web
developers who can use it correctly and get benefits from the
expressiveness.

On Wed, Apr 29, 2015 at 3:52 AM Ryosuke Niwa <rniwa@apple.com> wrote:

>
> > On Wed, Apr 29, 2015 at 2:09 AM Ryosuke Niwa <rniwa@apple.com> wrote:
> >>
> >> > On Apr 27, 2015, at 9:50 PM, Hayato Ito <hayato@chromium.org> wrote:
> >> >
> >> > The feature of "<shadow> as function" supports *subclassing*. That's
> exactly the motivation I've introduced it once in the spec (and implemented
> it in blink). I think Jan Miksovsky, co-author of Apple's proposal, knows
> well that.
> >>
> >> We're (and consequently I'm) fully aware of that feature/prosal, and we
> still don't think it adequately addresses the needs of subclassing.
> >>
> >> The problem with "<shadow> as function" is that the superclass
> implicitly selects nodes based on a CSS selector so unless the nodes a
> subclass wants to insert matches exactly what the author of superclass
> considered, the subclass won't be able to override it. e.g. if the
> superclass had an insertion point with select="input.foo", then it's not
> possible for a subclass to then override it with, for example, an input
> element wrapped in a span.
> >>
> >> > The reason I reverted it from the spec (and the blink), [1], is a
> technical difficulty to implement, though I've not proved that it's
> impossible to implement.
> >>
> >> I'm not even arguing about the implementation difficulty. I'm saying
> that the semantics is inadequate for subclassing.
>
> > On Apr 28, 2015, at 10:34 AM, Hayato Ito <hayato@chromium.org> wrote:
> >
> > Could you help me to understand what "implicitly" means here?
>
> I mean that the superclass’ insertion points use a CSS selector to select
> nodes to distribute. As a result, unless the subclass can supply the
> exactly kinds of nodes that matches the CSS selector, it won’t be able to
> override the contents into the insertion point.
>
> > In this particular case, you might want to blame the super class's
> author and tell the author, "Please use <content select=.input-foo> so that
> subclass can override it with arbitrary element with class="input-foo”.
>
> The problem is that it may not be possible to coordinate across class
> hierarchy like that if the superclass was defined in a third party library.
> With the named slot approach, superclass only specifies the name of a slot,
> so subclass will be able to override it with whatever element it supplies
> as needed.
>
> > Could you give me an concrete example which <content slot> can support,
> but "<shadow> as function" can't support?
>
> The problem isn’t so much that slot can do something "<shadow> as
> function" can’t support. It’s that "<shadow> as function" promotes over
> specification of what element can get into its insertion points by the
> virtue of using a CSS selector.
>
> Now, it's possible that we can encourage authors to always use a class
> name in select attribute to support this use case. But then why are we
> adding a capability that we then discourage authors from using it.
>
> - R. Niwa
>
>