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

Re: Proposal for changes to manage Shadow DOM content distribution

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 22 Apr 2015 12:55:50 -0700
Message-ID: <CAAWBYDBb_ef_AGaHq+pbHias66oaYHX9WX9VqR-Hw_Q2xKz0rQ@mail.gmail.com>
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

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