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

Re: Proposal for changes to manage Shadow DOM content distribution

From: Hayato Ito <hayato@chromium.org>
Date: Wed, 22 Apr 2015 23:08:24 +0000
Message-ID: <CAFpjS_1SmkaqQqdfRk+BGUPxYhaKjmTa94dTrERj61ay18bDPA@mail.gmail.com>
To: Dimitri Glazkov <dglazkov@google.com>, Ryosuke Niwa <rniwa@apple.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Domenic Denicola <d@domenic.me>, Brian Kardell <bkardell@gmail.com>, "Edward O&amp,#39 Connor" <eoconnor@apple.com>, Jan Miksovsky <jan@component.kitchen>, WebApps WG <public-webapps@w3.org>
For the comparison, I've re-written the examples by using "<shadow> as
function" syntax.

https://gist.github.com/hayatoito/f2df8e10cb8cc551f80c

Can I assume that both have the same power, fundamentally?
(Please ignore that power of the CSS selector here ;)

If both approaches have the (almost) equivalent power, I guess the
technical difficulties to implement these features don't differ so much.
If we could implement the new proposal, I think we could implement
"<shadow> as function" too.



On Wed, Apr 22, 2015 at 3:56 PM Dimitri Glazkov <dglazkov@google.com> wrote:

> FWIW, I can see the appeal of a slot-based approach in Ryosuke/Ted/Jan
> proposal.
>
> It reduces the implementation complexity: all of the selector-checking
> logic in
> http://w3c.github.io/webcomponents/spec/shadow/#satisfying-matching-criteria
> is replaced with (what effectively is) a map lookup.
>
> While some loss of flexibility is a cost, I think it's worth considering
> this trade-off, especially if it is a sticking point for implementers who
> are looking to reduce the overall cost of Shadow DOM implementation.
>
> In fact, if we reach cross-vendor agreement and decide to go with the
> slot-based approach, we probably should avoid adding extra sugar around
> element names and attribute values as slot indicators, and instead double
> down on developing a good imperative API that overcomes the loss of
> flexibility.
>
> :DG<
>
Received on Wednesday, 22 April 2015 23:08:53 UTC

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