On Thu, Apr 30, 2015 at 6:38 PM Ryosuke Niwa <rn...@apple.com> wrote:
> > > 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. > > This is not true. The resolution is: The decision is blocked on "The upcoming proposal of Imperative APIs". > - R. Niwa > >
