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

I disagree, many of the components we've written rely on the addition of
top-level, delegated events. The developer would be forced to listen for
the DOMElementsUpgraded/DOMComponentsLoaded in some other script to add
these basic features for their component - and it would require an even
more contorted workaround if their component definition was loaded
dynamically after page load, because
DOMElementsUpgraded/DOMComponentsLoaded only fires for original source
elements.



On Fri, Apr 12, 2013 at 2:35 PM, Scott Miles <sjmiles@google.com> wrote:

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