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

That's extreme, I believe there are probably many ways to skin those cats.
The prototype could include some kind of 'staticInitCallback', for example.


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

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