Re: [webcomponents] Binding Custom Element without Polluting Global Scope (Was Proposal for Cross Origin Use Case and Declarative Syntax)

On Sat, Dec 7, 2013 at 10:06 AM, Ryosuke Niwa <rniwa@apple.com> wrote:

> On Dec 6, 2013, at 5:01 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>
> 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?
>
>
> I'll also point out that with our proposal to add an optional template
> argument, we could do:
>
> <template id=myButton>
> ...
> </template>
> <script>
> (function () {
>     class MyButton extends HTMLElement {
>         ...
>     }
>     document.register('my-button', MyButton,
> document.getElementById('myButton'));
> )();
> </script>
>
> so authors DO have an option to hide the class entirely from the global
> scope. It's just not declarative.
>

I don't think this proposal is an improvement over the document.register in
the spec today. Whether there is an argument for a template element is
orthogonal to adding a binding to the JavaScript scope.

The existing spec for document.register does not add a binding to the
JavaScript scope. So it does not suffer the problem discussed in this
thread.


> Given that we don't want to change "this" or the global object per
> previous discussion in the working group,
>

I don't know what discussion you are specifically referring to so my next
statement is not agreeing or disagreeing with the preceding clause of this
sentence.


> I don't see how we can refer to a JS class/constructor declaratively.
>

Yes. I can't think of an example where DOM attributes do this. onclick,
etc. handlers relate to script, but they do not refer to specific objects.

This is a problem with your proposal.

I think a proposal for declarative Custom Elements must also deal with the
problems the group discovered when it last tried. They are summarized here:

<http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0287.html>

Link provided for convenience, as you are no doubt aware of these.

-- 
<http://goto.google.com/dc-email-sla>