For the comparison, I've re-written the examples by using "<shadow> as
function" syntax.

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

Reply via email to