Re: [webcomponents]: Platonic form of custom elements declarative syntax

Have to lean towards Raf and Daniel on this one. Making a element
registation a concern of <template> doesn't feel right. In this case, explicit
structure and a few more characters is worth it.

On Wed, Apr 10, 2013 at 9:00 PM, Daniel Buchner <daniel@mozilla.com> wrote:

> It's incredibly important that we agree that association of a <template>
> with <element> happens on the element side, something like: <element
> template="foo-template"> (or by placing the template inside element, if
> that is the API we want). I don't think this part is opinion, but because
> doing the reverse - marking on the <template> which <element> it refers to
> - hinders a few valid use-cases:
>
>    - one <template> from being used by many different <elements>
>    - changing a template association on a single instance of an element
>    type
>       - say you have an <x-foo> on the page that you want to switch
>       template associations on, but not for every other <x-foo> in the document.
>       Wouldn't this case be far more clear cut if you could just query for the
>       element and change some property? For instance: fooElement.template =
>       'foo-template-2'; Boom! This particular foo element just switched templates.
>
> Shouldn't we prevent such a thing? I can't redefine a <button>'s
"template.  There should be some guarantee I'm getting the same <x-foo>
(API, look and feel) after it's been registered. What's the use case for
swapping in a new template?

>
>    -
>
>
>
> On Wed, Apr 10, 2013 at 8:19 PM, Daniel Buchner <daniel@mozilla.com>wrote:
>
>> Here are a few (compelling?) answers/arguments:
>>
>>    1. Style elements had never done this before, yet it rocks socks:
>>    <style scoped>
>>    2. It would be new for script elements, but hardly new for other
>>    elements. There are plenty of elements that have various behaviors or
>>    visual representations only when placed inside specific elements. Given
>>    this is already an advanced web API, I'm not sure a little upfront learning
>>    is a huge concern. We could even allow for this, given the paradigm is
>>    already established: <script scoped>  *// could scope 'this' ref to
>>    the parentNode*
>>    3. Are you referring to <template> attachment here? If so, I agree,
>>    thus the proposal I submitted allows for both (
>>    https://gist.github.com/csuwldcat/5360471). If you want your template
>>    automatically associated with your <element>, put it inside, if not, you
>>    can specify which <template> a custom element should use by reference to
>>    its ID.
>>
>>
>> On Wed, Apr 10, 2013 at 8:00 PM, John J Barton <
>> johnjbarton@johnjbarton.com> wrote:
>>
>>>
>>>
>>>
>>> On Wed, Apr 10, 2013 at 6:51 PM, Dimitri Glazkov <dglazkov@google.com>wrote:
>>>
>>>> On Wed, Apr 10, 2013 at 6:38 PM, Rick Waldron <waldron.rick@gmail.com>
>>>> wrote:
>>>> > Everyone's answer to this should be "no"; changing the expected value
>>>> of the
>>>> > top level "this", in some magical way, simply won't work.
>>>>
>>>> Can you explain why you feel this way?
>>>>
>>>
>>> 1) Because <script> has never done this before, so it better be
>>> compelling.
>>> 2) Because causing |this| to change by moving the <script> tag in the
>>> HTML or adding a layer of elements etc seems likely to cause hard to
>>> understand bugs.
>>> 3) Forcing the binding based on position is inflexible.
>>>
>>> To be sure this is implicit-declarative vs explicit-imperative bias, not
>>> evidence.
>>>
>>> Oh, sorry you were asking Rick.
>>>  jjb
>>>
>>
>>
>