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

Re: Proposal for changes to manage Shadow DOM content distribution

From: Ryosuke Niwa <rniwa@apple.com>
Date: Tue, 21 Apr 2015 23:32:23 -0700
Cc: Justin Fagnani <justinfagnani@google.com>, Daniel Freedman <dfreedm@google.com>, WebApps WG <public-webapps@w3.org>, Edward O'Connor <eoconnor@apple.com>, Jan Miksovsky <jan@component.kitchen>
Message-id: <47B90BB1-9090-4A09-A423-230BBA306C88@apple.com>
To: Domenic Denicola <d@domenic.me>

> On Apr 21, 2015, at 11:08 PM, Domenic Denicola <d@domenic.me> wrote:
> 
> From: Ryosuke Niwa [mailto:rniwa@apple.com] 
> 
>> 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].
> 
> <details> is such an example, I think? Is the following a correct example of what client code would have to look like for <details>, under the proposal?
> 
> <details>
>  <div content-slot="summary">Stuff</div>
>  <div content-slot="main">
>    <p>More</p>
>    <p>Stuff</p>
>  </div>
> </details>
> 
> or, if you wanted to avoid the wrapper div,
> 
> <details>
>  <div content-slot="summary">Stuff</div>
>  <p content-slot="main">More</p>
>  <p content-slot="main">Stuff</p>
> </details>

This can just be 

<details>
 <div content-slot="summary">Stuff</div>
 <p>More</p>
 <p>Stuff</p>
</details>

if our implementation had something along the line of:

<template element="details">
  <content slot="summary"></content>
  <content></content>
</template>

since we still support unnamed content element as the catch-all insertion point as it is today.

I'd rather not do it because it's rather confusing and arbitrary but if we really wanted to, it might be okay to allow element name as a slot-content name. e.g. the above example reduces to:

<details>
 <summary>Stuff</summary>
 <p>More</p>
 <p>Stuff</p>
</details>

That is, each element implicitly defines content-slot attribute with the value set to its element name.

- R. Niwa
Received on Wednesday, 22 April 2015 06:33:01 UTC

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