On Tue, May 19, 2015 at 12:06 PM Dimitri Glazkov <dglazkov@google.com>
wrote:
> On Mon, May 18, 2015 at 6:48 PM, Hayato Ito <hayato@chromium.org> wrote:
>
>> 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.
>>
>
> Those were never conjoined that much. Slots and multiple templates are
> part of the same proposal, but they are largely independent pieces. As for
> slots being a prerequisite for imperative APIs, I only remember it being
> mentioned in the sense that any flavor of declarative API should be
> implementable by the imperative API.
>
>
>>
>> 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.
>>
>
> Is the situation where no other vendors are willing to implement the
> current select not a strong reason?
>
>
Agreed.
> 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.
>>
>
> That's a good request. I'll work on the comparison, including Domenic's
> request to outline the constant-timeliness.
>
>
Thank you! I'm afraid that we don't have enough discussion about the pros
and cons between "select nodes using a selector" and "select nodes by a
fixed id using attribute".
I'd like to make sure that everyone understand the pros and cons for both
as a separated topic from "Imperative APIs and Multiple Templates" so that
we can do the best judgement.
> :DG<
>