On Mon, May 18, 2015 at 6:34 PM, Domenic Denicola <d@domenic.me> wrote:
> From: Justin Fagnani [mailto:justinfagnani@google.com]
>
> > They're not equivalent, because any element can have the right
> content-slot value, but with tag names, only one (or maybe N) names would
> be supported.
>
> Hmm, I don't understand, and fear we might be talking past each other. Can
> you give an example where content-slot works but tag names do not? For
> example
> https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution.md#proposal-part-1-syntax-for-named-insertion-points
> gets translated from
>
> <combo-box>
> <icon></icon>
> <dropdown>
> … Choices go here …
> </dropdown>
> </combo-box>
>
> Your stated sentence doesn't make much sense to me; you can have multiple
> elements with the same tag name. Literally, just take any example you can
> write <x content-slot="y"> ... </x> and replace those with <y> and </y>.
>
Given the widget <ui-collapsible> that expects a ui-collapsible-header in
the content model, with slots I can write:
<ui-collapsible>
<my-header-v1 slot="ui-collapsible-header"> ... </...>
</ui-collapsible>
<ui-collapsible>
<my-header-v2 slot="ui-collapsible-header"> ... </...>
</ui-collapsible>
within the same application. It also means the library can ship with an
implementation of the header widget, but you can replace it with your own.
This is identical to the common usage today in polymer apps where you
annotate your own element with classes. There's no restriction on the type
of the input.
With tag names I must write:
<ui-collapsible>
<ui-collapsible-header> ... </...>
</ui-collapsible>
which means I can't replace the header with any widget I choose, I must use
that custom element. This is identical to using a tag name with <content
select> and it restricts the type of input. There's no way to have both an
implementation in the library and one in your application, or multiple
implementations.
- E