W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2013

[webcomponents]: Of weird script elements and Benadryl

From: Dimitri Glazkov <dglazkov@google.com>
Date: Fri, 12 Apr 2013 12:30:35 -0700
Message-ID: <CADh5Ky13gTUMjNMU8r7XdoC-nQC=mMZLkSz-_M-GZVR1c4YECA@mail.gmail.com>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
Cc: Rick Waldron <waldron.rick@gmail.com>, Daniel Buchner <daniel@mozilla.com>, John J Barton <johnjbarton@johnjbarton.com>, Scott Miles <sjmiles@google.com>, Rafael Weinstein <rafaelw@google.com>, public-webapps <public-webapps@w3.org>, Blake Kaplan <mrbkap@mozilla.com>, William Chen <wchen@mozilla.com>, Jonas Sicking <jonas@sicking.cc>, Steve Orvell <sorvell@google.com>, Dave Herman <dherman@mozilla.com>, Boris Zbarsky <bzbarsky@mit.edu>
... 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">
    <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) 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.

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.

So far, I haven't seen any other workable alternatives. TC39 peeps and
others, help me find them.

:DG<
Received on Friday, 12 April 2013 19:31:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:18:49 UTC