My preference in v1:
1. select (strongly preferred). okay to rename it if we have a better name.
e.g. <content select=xxx> ==> <slot select=xxx>
2. select + content-slot
3. content-slot
I was assuming that "content-slot" is one of required parts in the
"Multiple Templates" proposal and "Imperative APIs".
Both, "Multiple Templates" and "Imperative APIs" are deferred to v2. There
is still no convincing proposal about how these are interacted in the
future.
I'd like to see a concrete proposal which explains all together in v2. For
v1, I don't see any strong reason to replace the current select.
I am not fan of bedding something which is unclear.
Could someone summarize the pros and cons of content-slot, compared to
select?
For me, cons are much bigger than pros in v1. I don't want to miss anything.
On Tue, May 19, 2015 at 10:37 AM 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>.
>
>