On Sat, Apr 13, 2013 at 1:47 AM, Daniel Buchner <daniel@mozilla.com> wrote:
> @Rick - I double checked with a few other folks today, and there is
> nothing that precludes the proposal of auto-generating a constructor that
> is put in scope before the script tag executes:
>
> <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?
>>
>> *>>> *This is not an issue --> *ReferenceError: XFooElement is not
>> defined *
>>
>
It's completely unclear that some magical incantation has defined this
constructor function or prototype object in the current scope.
>
>>
> Given the parent <element> is parsed before the script tag is hit, there's
> no reason a constructor object can't be created an put in scope before the
> script tag is evaluated.
>
This effectively implies that some "magic" global code is executed before
any <element> nested <script> code. What happens when my custom element
prototype methods aren't in that nested <script>? What if I want to
initialize some kind of internal state with my own constructor in a class
that extends HTMLElement?
Why is there such a strong desire to create new <script> semantics? John J
Barton and three members of TC39, Allen, Erik and myself, have all warned
against it. John, Allen and I have also offered completely simple and
reasonable alternatives that satisfy most—if not all—use cases.
Rick