- From: Ryosuke Niwa <rniwa@apple.com>
- Date: Thu, 15 Jan 2015 18:43:41 -0800
- To: Dimitri Glazkov <dglazkov@google.com>
- Cc: Domenic Denicola <d@domenic.me>, Erik Arvidsson <arv@google.com>, Anne van Kesteren <annevk@annevk.nl>, Boris Zbarsky <bzbarsky@mit.edu>, public-webapps <public-webapps@w3.org>
> On Jan 14, 2015, at 12:52 PM, Dimitri Glazkov <dglazkov@google.com> wrote: > > FWIW, I think that element upgrade is sort of fundamental to the usefulness of custom elements. In a world where most scripts are non-blocking (that's hopefully the modern world we should aim for), I'll effectively expect to walk the tree anyway. Allowing loading scripts asynchronously, including ones that define custom elements, is one thing; automatically resolving script dependencies for custom elements is another. When an author imports a ES6 module, we don't create a fake object which gets resolved later by rewriting its prototype. Even if we were to agree this is desirable, I don't think we're ready to bake the exact mechanism by which such asynchronous custom elements upgrades happens in the browser since the introduction of ES6 models is likely rewriting the landscape of how authors load external dependencies soon. Of course, I'm sympathetic to the view that we should make upgrading easier; e.g. by exposing the list of event listeners attached on an element so that replacing/cloning an element will be easier. - R. Niwa
Received on Friday, 16 January 2015 02:44:14 UTC