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 10:26:29 +0000
Message-ID: <CAFpjS_0Xp_sjyyiPMtXh153n3mqjHiML94L4XqGVrR5vcpf=Og@mail.gmail.com>
To: Ryosuke Niwa <rniwa@apple.com>
Cc: WebApps WG <public-webapps@w3.org>
For reference, the discussion about "<shadow> as function" was done in W3C
bugzilla, https://www.w3.org/Bugs/Public/show_bug.cgi?id=22344, where everyone
in the discussion agreed with the proposal.


On Thu, Apr 30, 2015 at 7:03 PM Hayato Ito <hayato@chromium.org> wrote:

> On Thu, Apr 30, 2015 at 6:38 PM Ryosuke Niwa <rniwa@apple.com> wrote:
>
>>
>> > On Apr 30, 2015, at 1:47 AM, Hayato Ito <hayato@chromium.org> wrote:
>> >
>> > Thanks, let me update my understanding:
>> >
>> > - There is no use cases which "<shadow> as function" can't support, but
>> "<content slot>" can support.
>> > - The purpose of the proposal is to remove an *extra* syntax. There is
>> no other goals.
>> > - There is no reason to consider "<content slot>" proposal if we have a
>> use case which this *extra* syntax can achieve.
>>
>> That's not at all what I'm saying. As far as we (Apple) are concerned,
>> "<shadow> as a function" as a mere proposal just as much as our "<content
>> slot>" is a proposal since you've never convinced us that "<shadow> as a
>> function" is a good solution for shadow DOM inheritance. Both proposals
>> should be evaluated based on concrete use cases.
>>
>> And even if there are use cases for which a given proposal (either
>> <shadow> as a function" or named slot) doesn't adequately address, there
>> are multiple options to consider:
>> 1. Reject the use case because it's not important
>> 2. Defer the use case for future extensions
>> 3. Modify the proposal as needed
>> 4. Reject the proposal because above options are not viable
>>
>> > I'm also feeling that several topic are mixed in the proposal,
>> "Imperative APIs, Multiple Templates and <content slot>", which makes me
>> hard to understand the goal of each.
>> > Can I assume that the proposal is trying to remove "<content select>",
>> not only from such a multiple templates, but also from everywhere?
>>
>> As I understand the situation, the last F2F's resolution is to remove
>> <content select> entirely. That's not a proposal but rather the tentative
>> consensus of the working group. If you'd like, we can initiate a formal CfC
>> process to reach a consensus on this matter although I highly doubt the
>> outcome will be different given the attendees of the meeting.
>>
>>
> This is not true.
> The resolution is: The decision is blocked on "The upcoming proposal of
> Imperative APIs".
>
>
>
>> - R. Niwa
>>
>>
Received on Thursday, 30 April 2015 10:26:58 UTC

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