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

*"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?"*

We've come across various occasions where we have a custom element, let's
say it's an <x-todo>, that has multiple content/view states (not something
achievable by a simple class/style change). There may be 200 of these
elements in a "summary view" in the list panel of the page in question.
When the user performs an action that requires an <x-todo> in summary view
to display a more complex, "detail view", we've found that the easiest way
to reuse elements, make the change in the least amount of code, and avoid
the cumbersome and repetitive paradigm of creating specific
<x-todo-summary> and <x-todo-detail> elements for this purpose, is to
simply have two different <template> elements for each view type. The views
can be radically different in structure and visual style - yet thanks to
our ability to simply swap out the template association on the specific
<x-todo> in question, the whole thing is a snap: myTodoElement.template =
'detail-template';

Does this help clarify a bit?



On Wed, Apr 10, 2013 at 10:05 PM, Eric Bidelman <ericbidelman@google.com>wrote:

> 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
>>>>
>>>
>>>
>>
>