- From: Ryosuke Niwa <rniwa@apple.com>
- Date: Fri, 06 Dec 2013 17:01:03 -0800
- To: Brian Di Palma <offler@gmail.com>
- Cc: Dimitri Glazkov <dglazkov@chromium.org>, "public-webapps@w3.org WG" <public-webapps@w3.org>
On Dec 6, 2013, at 1:20 AM, Brian Di Palma <offler@gmail.com> wrote:
> On Fri, Dec 6, 2013 at 3:24 AM, Ryosuke Niwa <rniwa@apple.com> wrote:
>> On Nov 12, 2013, at 12:45 AM, Ryosuke Niwa <rniwa@apple.com> wrote:
>>
>> On Nov 12, 2013, at 8:12 AM, Dimitri Glazkov <dglazkov@chromium.org> wrote:
>>
>> 1) It is not friendly to ES6 classes. In fact, you can't use class syntax
>> and this syntax together.
>>
>>
>> Okay, let the author define the constructor.
>>
>> 3) The approach pollutes global name space with constructors. This had been
>> voiced many times as unacceptable by developers.
>>
>>
>> We can solve this problem by using JavaScript "object path" as opposed to a
>> variable name.
>>
>> So instead of:
>> <template register="my-button" interface="MyButton">
>> </template>
>>
>> We allow:
>> <script>
>> var my = {views:{MyButton: ~}};
>> </script>
>> <template register="my-button" interface="my.views.MyButton">
>> </template>
>>
>> While this requires some variable to be exposed on the global scope,
>> libraries and frameworks do this already,
>
> Hopefully though they won't do that any longer in the ES6 module world.
> They had to be exposed on the global scope in some way otherwise they
> couldn't be used, in future that will no longer be the case.
Are you proposing to provide some mechanism to declaratively define a custom element inside a module?
How does a ES6 module end up having markup?
- R. Niwa
Received on Saturday, 7 December 2013 01:01:40 UTC