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 <dglaz...@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< >
