Re: Inheritance Model for Shadow DOM Revisited

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

- R. Niwa

Received on Thursday, 30 April 2015 09:38:42 UTC