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

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

From: Rick Waldron <waldron.rick@gmail.com>
Date: Fri, 12 Apr 2013 16:25:58 -0400
Message-ID: <CAHfnhfof9pubFeVbRwqcpxp4h-LwTc+TCkKkWGLTe=fJHSwZHw@mail.gmail.com>
To: Dimitri Glazkov <dglazkov@google.com>
Cc: Allen Wirfs-Brock <allen@wirfs-brock.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>
On Fri, Apr 12, 2013 at 3: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">
>     <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
>

Based on what? Is this more magic? What if a constructor is provided?

Here are a few use case, followed by a proposed set of semantics:


Given the following custom element:

  <element name="foo-bar">
    <template></template>
  [
    <script>
      class FooBar {}
    </script>
  ]
  </element>

The braces are used to illustrate that the script tag is optional, so it
might also look like:

  <element name="foo-bar">
    <template></template>
  </element>


OR
  <!-- elsewhere in the document -->
  <script>
    class FooBar {}
  </script>

OR
  (in a remote src file)
  class FooBar {}

OR
  (in a module)
  module CustomElements {
    export class FooBar {}
  }

  (that's later imported)
  import { FooBar } from "CustomElements";



(None of the following is precise, just a basic idea that works with every
example I've given above)


Script tags inside <element> are treated the same way as any script tag in
an HTML document would be treated.


[[ConvertName]] is an imaginary operation the does the following:
  Let _converted_ be the result of
    1. replacing the first character of argument _val_ with same character
converted to ASCII uppercase
    2. replacing each U+002D (HYPHEN-MINUS character '-') that is followed
by a lowercase ASCII letter, by removing the U+002D and converting the
lowercase letter that followed with the same uppercase ASCII character.
  Return _converted_.


For each <element>
  Parse <template> (I don't know what happens here, so just play along)
  Let _val_ be the value of the **name** attribute of <element>
  Let _name_ be the result of calling [[ConvertName]] with the argument
_val_
  Let _ctor_ be the result of calling Get([[Global]], _name_)
  If _ctor_ is undefined
    - Create a new class whose Identifier is _name_ which extends from
HTMLElement
      (This is just an assumption, replace with whatever makes the most
sense)
  Call document.register with arguments _val_ and _ctor_



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

Please don't trivialize valid concerns—it wasn't just John and I, Erik and
Allen echo'ed the same.


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

see above.


>
> :DG<
>


Rick
Received on Friday, 12 April 2013 20:26:49 UTC

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