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

On Fri, Apr 12, 2013 at 2:06 PM, John J Barton
<johnjbarton@johnjbarton.com> wrote:

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

I completely didn't get that, but it sounds like a slightly different topic?

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

We're not calling new FooBar anywhere in here. All the <element> does
is registers a custom element with the parser and blesses it to be a
real DOM object.

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

The |this| hack was just a way to solve the problem of connecting
<element> and <script> somehow. I am not sure understand what you're
saying (suggesting?) here, either :)

:DG<

Received on Friday, 12 April 2013 22:32:02 UTC