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

On Fri, Apr 12, 2013 at 6:20 PM, Dimitri Glazkov <dglazkov@google.com>wrote:

> On Fri, Apr 12, 2013 at 1:25 PM, Rick Waldron <waldron.rick@gmail.com>
> wrote:
> >
> >
> >
> > 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?
>
> Generated constructor is an unfortunate side effect of platform
> constraints. Here's a nice summary:
> http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0728.html.
>
> We'll have to live with them if we want to make progress in foreseeable
> future.
>
> > 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_
>
> Basically, <element> relies on the constructor already being already
> set on the global object. Did I get this right?
>
> It's straightforward, but I have a couple of concerns:
>
> 1) there was discussion very early on about allowing custom elements
> polluting the global namespace. For example, peeps may want to define
> Toolkit.UI.Flinger directly.
>

In that case, use JJB's suggestion and provide a constructor attribute:

<element name="foo" constructor="Toolkit.UI.Flinger">
  <template></template>
[
  <script>
  // assumes that Toolkit.UI is in scope, otherwise this will throw a
reference error
  Toolkit.UI.Flinger = function() {
     // initialize flingable thingers
  }
  </script>
]
</element>


Of course... that can also be in a remote script src:

Toolkit = {
  UI: {
    Flinger: function() {
      // initialize flingable thingers
    }
  }
};



> 2) since we do have to live with generated constructors -- at least
> for a little while, we have two decoupled operations:
>
> a) create prototype
> b) generate constructor.


> How would they be synchronized? In other words, in your example, when
> FooBar is defined, the constructor hasn't been generated yet. I guess
> <element> could just stomp over it.
>

I'm not following you here... I might be mistaken, but I think we have a
terminology mix-up: FooBar (ie. class FooBar {} ) is the constructor,
nothing to generate, but I don't quite know what step you're referring to
when you say "the constructor hasn't been generated yet". :\



>
>
> >
> > Please don't trivialize valid concerns—it wasn't just John and I, Erik
> and
> > Allen echo'ed the same.
>
> Wouldn't have ever thought of it. Poking lighthearted fun--maybe.
> Trivializing--never! :)
>

Fair enough ;)


>
> :DG<
>