W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2015

Re: Inheritance Model for Shadow DOM Revisited

From: Hayato Ito <hayato@chromium.org>
Date: Thu, 30 Apr 2015 10:03:54 +0000
Message-ID: <CAFpjS_0Eb-o8xV43pqdazwDOBPynyJXUo=oYa1v1-_PooZLodA@mail.gmail.com>
To: Ryosuke Niwa <rniwa@apple.com>
Cc: WebApps WG <public-webapps@w3.org>
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
Received on Thursday, 30 April 2015 10:04:22 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:31 UTC