> On Apr 22, 2015, at 3:48 PM, Justin Fagnani <justinfagn...@google.com> wrote: > > On Wed, Apr 22, 2015 at 2:37 PM, Ryosuke Niwa <rn...@apple.com > <mailto:rn...@apple.com>> wrote: > >> On Apr 22, 2015, at 10:16 AM, Justin Fagnani <justinfagn...@google.com >> <mailto:justinfagn...@google.com>> wrote: >> >> On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa <rn...@apple.com >> <mailto:rn...@apple.com>> wrote: >> >> > On Apr 21, 2015, at 10:23 PM, Justin Fagnani <justinfagn...@google.com >> > <mailto:justinfagn...@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. > > What are concrete use cases that require such flexibility? > > Require is a strong word :) but the case I recently experienced was a panel > with a header. It always expects one child for the header and the rest for > content. There are several ways to do this, and one would be to select the > first child into one distribution point and the rest into another. Another > way is to use attributes, classes or a specific set of tag names. The key for > me here is that you give the custom element author a choice on how to shape > their API.
I don't think letting authors of each component choose how to select nodes of distributions will increase the inconsistencies between components written by different authors and deteriorate the ergonomics of component users. >> <template> >> <content select=".header"></content> >> <content select=":not(.footer)"></content> >> <content select=".footer"></content> >> </template> > > Our point wasn't so much that it's not achievable. With enough hackeries and > "techniques", we can. The problem is the developer ergonomics of content > element with select attribute with common real world use cases. For example, > the above code is a lot more verbose and less intuitive than > >> <template> >> <content slot="header"></content> >> <content></content> >> <content slot="footer"></content> >> </template> > > This is true, but it's a trade off for custom element authoring brevity vs > custom element use brevity (and authoring expressiveness). I'd personally > rather optimize for custom element user ergonomics, and give custom element > authors the power to make their elements easy and convenient. > > Continuing this example I would actually make the selectors more complex > because we have these nice semantic elements in html5: >> <template> >> <content select="header, .header"></content> >> <content select=":not(footer, .footer)"></content> >> <content select="footer, .footer"></content> >> </template> > > Which is more work for the CE author, but allows this for the user: > >> <my-element> >> <header>Title</header> >> <p>...</p> >> <p>...</p> >> <footer>...</footer> >> </my-element> That's a fair point but it is a feature that the user of components needs to explicitly opt-in to use slot-content. That explicit contract ensures the API surface to be limited. Suppose in the version 1 of this component, it only supported "header". If the version 2 of this component subsequently added the support for "footer", it's unclear whether every existing use of "footer" element is appropriate for node distribution. This poses a serious challenge for adding new features to your components. In addition, such an explicit contract is a must-have requirement for cross-origin components we (Apple's WebKit team) have been advocating for years now. - R. Niwa
