- From: Ryosuke Niwa <rniwa@apple.com>
- Date: Tue, 28 Apr 2015 10:09:55 -0700
- To: Hayato Ito <hayato@chromium.org>
- Cc: WebApps WG <public-webapps@w3.org>, Jan Miksovsky <jan@component.kitchen>
> 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. - R. Niwa
Received on Tuesday, 28 April 2015 17:10:34 UTC