FWIW, we're working to implement what we call named blocks in Ember.js and believe this proposal aligns very closely to what our users have been asking us to build for them.
- Erik On Wednesday, April 22, 2015, Tab Atkins Jr. <jackalm...@gmail.com> wrote: > This is literally reinventing Selectors at this point. The solution > to "we don't think it's worth implementing *all* of Selectors" is to > define a subset of supported Selectors, not to define a brand new > mechanism that's equivalent to selectors but with a new syntax. > > On Wed, Apr 22, 2015 at 10:21 AM, Justin Fagnani > <justinfagn...@google.com <javascript:;>> wrote: > > Another technique I've seen used is compound selectors, which could be > used > > to migrate from one selector to another while preserving backwards > > compatibility, or to provide some nice default distributions that are > also > > accessible via a class or attribute (ie, select="header, .header"). > > > > Could slots have multiple names to support something like this? > > > > On Wed, Apr 22, 2015 at 10:16 AM, Justin Fagnani < > justinfagn...@google.com <javascript:;>> > > wrote: > >> > >> > >> > >> On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa <rn...@apple.com > <javascript:;>> wrote: > >>> > >>> > >>> > On Apr 21, 2015, at 10:23 PM, Justin Fagnani < > justinfagn...@google.com <javascript:;>> > >>> > wrote: > >>> > > >>> > I do want the ability to redirect distributed nodes into a holes in > the > >>> > base template, so that part is welcome to me. However, my first > reaction to > >>> > the slot idea is that forcing users to add the content-slot > attribute on > >>> > children significantly impairs the DOM API surface area of custom > elements. > >>> > > >>> > For the single-level distribution case, how is this different from > >>> > <content select="[content-slot=name]"> except that content select can > >>> > distribute based on features of the children that might already > exist, like > >>> > tag names or an attribute? > >>> > >>> At the conceptual level, they're equivalent. However, we didn't find > the > >>> extra flexibility of using CSS selectors compelling as we mentioned in > our > >>> proposal [1]. > >> > >> > >> I personally would like to see more power, especially positional > >> selectors. Some components would be better off selecting their first > child, > >> rather than requiring a class. > >>> > >>> > >>> [1] See points 3 and 4 in > >>> > https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec > >> > >> > >> Point 4 is interesting, because unless I'm missing something (which > could > >> be!) it's incorrect. You can create selectors with :not() that exclude > the > >> content selectors that come after in document order. I would rewrite the > >> example as: > >> > >> <template> > >> <content select=".header"></content> > >> <content select=":not(.footer)"></content> > >> <content select=".footer"></content> > >> </template> > >> > >> Cheers, > >> Justin > >> > >>> > >>> > >>> > >>> - R. Niwa > >>> > >> > > > >
