Re: Inheritance Model for Shadow DOM Revisited

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