- From: Ryosuke Niwa <rniwa@apple.com>
- Date: Tue, 28 Apr 2015 11:52:56 -0700
- To: Hayato Ito <hayato@chromium.org>
- Cc: WebApps WG <public-webapps@w3.org>, Jan Miksovsky <jan@component.kitchen>
> 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