- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 22 Apr 2015 12:55:50 -0700
- To: Justin Fagnani <justinfagnani@google.com>
- Cc: Ryosuke Niwa <rniwa@apple.com>, Daniel Freedman <dfreedm@google.com>, WebApps WG <public-webapps@w3.org>, "Edward O'Connor" <eoconnor@apple.com>, Jan Miksovsky <jan@component.kitchen>
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 <justinfagnani@google.com> 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 <justinfagnani@google.com> > wrote: >> >> >> >> On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa <rniwa@apple.com> wrote: >>> >>> >>> > On Apr 21, 2015, at 10:23 PM, Justin Fagnani <justinfagnani@google.com> >>> > 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 >>> >> >
Received on Wednesday, 22 April 2015 19:56:38 UTC