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

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.

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.


>
> 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! :)

:DG<

Received on Friday, 12 April 2013 22:21:12 UTC