Re: Proposal for changes to manage Shadow DOM content distribution

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