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

Re: Inheritance Model for Shadow DOM Revisited

From: Hayato Ito <hayato@chromium.org>
Date: Thu, 30 Apr 2015 16:24:42 +0000
Message-ID: <CAFpjS_0=kgBShJ5fYpb4DkH9su0XoKhYhT81LhEn5mzUfBrD6Q@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>, Ryosuke Niwa <rniwa@apple.com>
Cc: WebApps WG <public-webapps@w3.org>, Jan Miksovsky <jan@component.kitchen>
Filed as https://www.w3.org/Bugs/Public/show_bug.cgi?id=28587.

On Fri, May 1, 2015 at 1:16 AM Hayato Ito <hayato@chromium.org> wrote:

> Thanks Anne, I agree that it would be great to have something like this.
>
> I think it's too early for us to judge something because we don't have a
> well defined Imperative API as of now. Let's re-open this issue after we
> can see how an Imperative API goes.
> I'll file a bug for the spec about this inheritance challenge so that we
> can continue the discussion in the bugzilla.
>
>
> On Thu, Apr 30, 2015 at 8:43 PM Anne van Kesteren <annevk@annevk.nl>
> wrote:
>
>> On Tue, Apr 28, 2015 at 7:09 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>> > 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.
>>
>> So what if we flipped this as well and came up with an imperative API
>> for "<shadow> as a function". I.e. "<shadow> as an actual function"?
>> Would that give us agreement?
>>
>> It'd be great to have something like this available.
>>
>>
>> --
>> https://annevankesteren.nl/
>>
>
Received on Thursday, 30 April 2015 16:25:10 UTC

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