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

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