> On Apr 30, 2015, at 1:47 AM, Hayato Ito <hay...@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

Reply via email to