Re: [webcomponents]: Of weird script elements and Benadryl

I  think those things are nice but not necessary.

In particular, there was a long discussion at one point about how the
<template> is inert but a <script> tag has to 'do things'. I found it
useful to realize that at the basic level the script only 'does stuff'
because it's the only way to express the otherwise inert prototype.



On Fri, Apr 12, 2013 at 2:31 PM, Daniel Buchner <daniel@mozilla.com> wrote:

> @Scott - interesting, but there are valid reasons for having access to the
> global scope/document:
>
>    - Components that benefit from top-level delegation
>    - Components that need to analyze their destination environment before
>    codifying their definition
>
> Know what I mean?
>
> On Fri, Apr 12, 2013 at 2:25 PM, Scott Miles <sjmiles@google.com> wrote:
>
>> I realize this doesn't fit any existing conceptual model (that I know of)
>> but I think it's worth pointing out that all we really want to do is define
>> a prototype for the element (as opposed to running arbitrary script).
>>
>> Invented pseudo-code (not a proposal, just trying to identify a mental
>> model):
>>
>> <element name="x-foo" extends="<something>">
>>   <!-- prototype for markup -->
>>   <template>
>>   <template>
>>   <!-- prototype for instances -->
>>   <prototype>
>>     readyCallback: function() {
>>     },
>>     someApi: function() {
>>     },
>>     someProperty: null
>>   </prototype>
>> </element>
>>
>>
>> On Fri, Apr 12, 2013 at 2:13 PM, Erik Arvidsson <arv@chromium.org> wrote:
>>
>>> Daniel, what happens in this case?
>>>
>>> <element name="x-foo">
>>>   <script>
>>>     class XFoo extends SVGElement {
>>>     }
>>>   </script>
>>> </element>
>>>
>>> This points out 2 short comings with your proposal.
>>>
>>> 1. This would just replace the global constructor. That might be OK, and
>>> we can detect this override to register the class as needed.
>>> 2. Prefixing with HTML seems like an anti pattern.
>>>
>>>
>>> On Fri, Apr 12, 2013 at 5:08 PM, Daniel Buchner <daniel@mozilla.com>wrote:
>>>
>>>> @John - what about what I just sent through? It hops over the magical
>>>> rebinding issue (or so I think), your thoughts?
>>>>
>>>>
>>>> On Fri, Apr 12, 2013 at 2:06 PM, John J Barton <
>>>> johnjbarton@johnjbarton.com> wrote:
>>>>
>>>>>
>>>>> Some suggestions:
>>>>>
>>>>> On Fri, Apr 12, 2013 at 12:30 PM, Dimitri Glazkov <dglazkov@google.com
>>>>> > wrote:
>>>>>
>>>>>> ... or "How the heck do we initialize custom elements in declarative
>>>>>> syntax?"
>>>>>>
>>>>>> There were good questions raised about the nature of <script> element
>>>>>> in the "platonic form" thread. Consider this syntax:
>>>>>>
>>>>>> <element name="foo-bar">
>>>>>>
>>>>>
>>>>> <element constructor="FooBar">
>>>>>
>>>>>
>>>>>>     <script> ...</script>
>>>>>>     <template> ... </template>
>>>>>> </element>
>>>>>>
>>>>>> The way <element> should work is like this:
>>>>>> a) when </element> is seen
>>>>>> b) generate a constructor for this element
>>>>>>
>>>>>
>>>>> b) call the nominated ctor, new FooBar(elt).
>>>>>
>>>>> I'm unclear on the practical advantages the instance inheriting from
>>>>> HTMLElement (new FooBar(), prototype inherits) vs manipulating the element
>>>>> from the outside (new FooBar(elt), prototype Object).
>>>>>
>>>>>
>>>>>
>>>>>> b) run document.register
>>>>>> c) run initialization code
>>>>>>
>>>>>>  As I see it, the problem is twofold:
>>>>>>
>>>>>> 1) The <script> element timing is weird. Since <script> is
>>>>>> initialization code, it has to run after the </element> is seen. This
>>>>>> is already contrary to a typical <script> element expectations.
>>>>>>
>>>>>
>>>>> Why? new FooBar() has to be called, but the outer init is anytime
>>>>> before that.
>>>>>
>>>>>
>>>>>>
>>>>>> 2) The <script> element needs a way to refer to the custom element
>>>>>> prototype it is initializing. Enclosing it in a function and calling
>>>>>> it with <element> as |this| seemed like a simplest thing to do, but
>>>>>> Rick and John had allergic reactions and had to be hospitalized.
>>>>>>
>>>>>
>>>>> For me its the implicit declarative binding + wired in to 'this' that
>>>>> makes the
>>>>> original solution very magical and inflexible. I can understand
>>>>> ensuring that
>>>>> a component can be self-contained, but cannot understand why it needs
>>>>> an
>>>>> ordered and hierarchical when <script> isn't rendered.
>>>>>
>>>>>
>>>>>>
>>>>>> So far, I haven't seen any other workable alternatives. TC39 peeps and
>>>>>> others, help me find them.
>>>>>>
>>>>>
>>>>> Thanks for asking ;-)
>>>>>
>>>>>
>>>>>>
>>>>>> :DG<
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> erik
>>>
>>>
>>>
>>
>