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? Cheers, Justin On Tue, Apr 21, 2015 at 9:57 PM, Ryosuke Niwa <rn...@apple.com> wrote: > > On Apr 21, 2015, at 9:43 PM, Daniel Freedman <dfre...@google.com> wrote: > > Hi Ryosuke, > > I want to start by thanking you, Ted, and Jan for taking the time to make > this proposal. > > I read through the proposal, and had a quick question about how > redistribution should work with this slot concept. > I created a quick <date-range-combo-box> example that would take two date > inputs (start date and end date) and distribute them through the example > <date-combo-box>, but I found myself stuck. > I can't name the two date inputs with the same slot or they will end up in > only one of the <date-combo-box> content elements, but <date-combo-box> > only takes inputs with slot "inputElement". > > How should this work? > > I drafted a quick gist to illustrate this: > https://gist.github.com/azakus/676590eb4d5b07b94428 > > > <!-- instance --> > <date-range-combo-box> > <input type="date" content-slot="start"><!-- (1) --> > <input type="date" content-slot="end"><!-- (2) --> > </date-range-combo-box> > > <!— implementation of date-range-combo-box --> > <template> > <shadow> > <date-combo-box><!-- (3) --> > <!-- > How can input[content-slot="start"] end up in the <content > slot="inputElement"> > in the <date-combo-box> ? > --> > <content slot="start"></content> > </date-combo-box> > <date-combo-box><!-- (4) --> > <content slot="end"></content> > </date-combo-box> > </shadow> > </template> > > > Am I right in assuming that you want to "re-distribute" (1) into (3)'s and > (2) into (4)'s inputElements? If so, I'd imagine one possible syntax is as > follows: > > <template> > <shadow> > <date-combo-box><!-- (3) --> > <content slot="start" content-slot="inputElement"></content> > </date-combo-box> > <date-combo-box><!-- (4) --> > <content slot="end" content-slot="inputElement"></content> > </date-combo-box> > </shadow> > </template> > > > Here, the content elements are both creating slots and fulfilling slots. > > - R. Niwa > > On Tue, Apr 21, 2015 at 8:19 PM, Ryosuke Niwa <rn...@apple.com> wrote: > >> Hi all, >> >> Following WebApps discussion last year  and earlier this year  >> about template transclusions and inheritance in shadow DOM, Jan Miksovsky >> at Component Kitchen, Ted O'Connor and I (Ryosuke Niwa) at Apple had >> a meeting where we came up with changes to the way shadow DOM distributes >> nodes to better fit real world use cases. >> >> After studying various real world use of web component APIs as well as >> exiting GUI frameworks, we noticed that selector based node distribution as >> currently spec'ed doesn't address common use cases and the extra >> flexibility CSS selectors offers isn't needed in practice. Instead, we >> propose named insertion "slots" that could be filled with the contents in >> the original DOM as well as contents in subclasses. Because the proposal >> uses the same slot filling mechanism for content distributions and >> inheritance transclusions, it eliminates the need for multiple shadow >> roots. >> >> Please take a look at our proposal at >> https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution >> >>  >> https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html >>  >> https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0611.html >> >> > >