W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2015

Re: Proposal for changes to manage Shadow DOM content distribution

From: Justin Fagnani <justinfagnani@google.com>
Date: Tue, 21 Apr 2015 22:23:52 -0700
Message-ID: <CAEKsHmCGoYUhZyFGxLjo33ocozUMDiOkcT2b+pUhT=v_u-QVdQ@mail.gmail.com>
To: Ryosuke Niwa <rniwa@apple.com>
Cc: Daniel Freedman <dfreedm@google.com>, WebApps WG <public-webapps@w3.org>, "Edward O'Connor" <eoconnor@apple.com>, Jan Miksovsky <jan@component.kitchen>
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 <rniwa@apple.com> wrote:

>
> On Apr 21, 2015, at 9:43 PM, Daniel Freedman <dfreedm@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 <rniwa@apple.com> wrote:
>
>> Hi all,
>>
>> Following WebApps discussion last year [1] and earlier this year [2]
>> 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
>>
>> [1]
>> https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html
>> [2]
>> https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0611.html
>>
>>
>
>
Received on Wednesday, 22 April 2015 05:24:40 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:31 UTC