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

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

> @Rick - when you say "see above", to what are you referring?
>

Sorry, I should've linked to
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0155.htmlwhich
is a previous message in this same thread (hence "above") but I was
mobile and that's not easy on mobile devices ;)



> IMO we arrive at our intended outcome without introducing <script> scoping
> or attribute issues, and at the same time reducing boilerplate, with the
> following:
>
>
> <element tagname="x-foo" inherits="SVGElement">
>   <template>...</template>
>   <script>
>       XFooElement.prototype.bar = function(){...}
>       XFooElement.prototype.readyCallback = function(){...}
>   </script></element>
> </element>
>
> Where am I going wrong here?
>

ReferenceError: XFooElement is not defined


Rick


>
> On Fri, Apr 12, 2013 at 2:38 PM, Rick Waldron <waldron.rick@gmail.com>wrote:
>
>>
>>
>> On Friday, April 12, 2013, Scott Miles 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.
>>>
>>
>> This is exactly what my proposed semantics are based on.  (See above)
>>
>> Rick
>>
>>
>>>
>>>
>>>
>>> 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
>>>
>>>
>