W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2015

Re: Inheritance Model for Shadow DOM Revisited

From: Ryosuke Niwa <rniwa@apple.com>
Date: Tue, 28 Apr 2015 10:09:55 -0700
Cc: WebApps WG <public-webapps@w3.org>, Jan Miksovsky <jan@component.kitchen>
Message-id: <24568297-735C-449A-9FCA-EB596990E438@apple.com>
To: Hayato Ito <hayato@chromium.org>

> 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

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:31 UTC