> On Wed, Apr 29, 2015 at 2:09 AM Ryosuke Niwa <rn...@apple.com> wrote:
>> > On Apr 27, 2015, at 9:50 PM, Hayato Ito <hay...@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 <hay...@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 

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

Reply via email to