Re: Inheritance Model for Shadow DOM Revisited

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
>>
>>