@Rick - "This effectively implies that some "magic" global code is executed
before any <element> nested <script> code." <-- if I had a bitcoin
(pre-bubble pop, naturally) for every inference made in web programming,
I'd be on a yacht in a sunny place.
To be honest, I find this inference quite unremarkable and easy to grok -
perhaps this is because it's a well known 'thing' at this point that
<head>'s constructor is HTMLHeadElement, <button>'s is HTMLButtonElement,
and...well you get the picture. The fact is, *most *element constructor
names magically correspond with their associated tag names - that yacht has
sailed.
"Why is there such a strong desire to create new <script> semantics?" - I
don't see where this *is* new script semantics, to our developer-users
anyway. Scripts won't look or feel (or smell?) any different than they do
now.
We already decided to magically infer that custom elements are denoted by,
and require, the presence of a magical dash in the tag name - something
rather alien to existing tags - yet I heard no one vehemently opposed *that
*injection of new paradigm/magic...I digress.
Question: would you require a constructor="" attribute? I don't see how you
get away from that if you went this direction. It would be necessary for
two reasons:
- Without it, you would need to assume a constructor name - which is
basically what you want to avoid.
- There must be some constructor name or else <element> won't be able to
sanely register the tag.
For what it's worth, I have nothing against making constructor="" an option
that is used instead of the tag name, but why force extra boilerplate if
people would be just as comfortable dealing with a constructor name based
on the tag name they specify? (as elements do now)
On Sat, Apr 13, 2013 at 1:17 PM, Rick Waldron <waldron.rick@gmail.com>wrote:
>
>
>
> 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
>
>
>