Re: [webcomponents]: Declarative Custom Elements Take Umpteen, The Karate Kid Edition

So, I don't love the extra punctuation, but there are other good things
here. We do away with duplication of tag name and the magic
[something].register call.

Presumably I can still set up private members in a closure, like this (?):

<script>
  var privateStack = [];
  (class XFoo: HTMLElement { readyCallback() { privateStack.push(...); } });
</script>

The last critical bit is some way to access our <element>. We could have
another callback which is essentially a static, called once per <element>
to allow access to the <element> itself, but I don't know where we'd put it
other than on the prototype itself.

Scott



On Tue, May 14, 2013 at 2:09 PM, Elliott Sprehn <esprehn@gmail.com> wrote:

>
>
>
> On Tue, May 14, 2013 at 2:04 PM, Daniel Buchner <daniel@mozilla.com>wrote:
>
>>
>> On Tue, May 14, 2013 at 1:58 PM, Erik Arvidsson <arv@chromium.org> wrote:
>>
>>>
>>> <element name="foo-bar">
>>>    ...
>>>    <script>
>>>        class FooBar {
>>>            ...
>>>        };
>>>    </script>
>>> </element>
>>
>>
>> Is it then possible to explicitly return the class after definition? I'm
>> asking because <script> return value is something I was not aware of.
>>
>
> Yes, by wrapping it in parenthesis. The spec
> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-13.5 seems to
> say that (class X { }) returns X but class X { } at the top level returns
> undefined.
>
> Thankfully it's not too gross, you'd just have:
>
> <script>
> (class MyCustomWidget : HTMLElement {
>   // ...
> })
> </script>
>
> ...   ...
>>    <script>
>>        class FooBar {
>>            ...
>>        };
>>
>>        return FooBar;
>>
>>
>>
> "return" isn't valid in the top level execution block which sucks. It
> would nice if we relaxed that restriction and allowed a return up there.
>
> - E
>
>