On Sat, Dec 7, 2013 at 10:06 AM, Ryosuke Niwa <rn...@apple.com> wrote:
> On Dec 6, 2013, at 5:01 PM, Ryosuke Niwa <rn...@apple.com> wrote: > > On Dec 6, 2013, at 1:20 AM, Brian Di Palma <off...@gmail.com> wrote: > > On Fri, Dec 6, 2013 at 3:24 AM, Ryosuke Niwa <rn...@apple.com> wrote: > > On Nov 12, 2013, at 12:45 AM, Ryosuke Niwa <rn...@apple.com> wrote: > > On Nov 12, 2013, at 8:12 AM, Dimitri Glazkov <dglaz...@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>