Re: Inheritance Model for Shadow DOM Revisited

> 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

Received on Tuesday, 28 April 2015 18:53:26 UTC