- From: Ryosuke Niwa <rniwa@apple.com>
- Date: Mon, 12 Jan 2015 14:44:52 -0800
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Domenic Denicola <d@domenic.me>, WebApps WG <public-webapps@w3.org>
Received on Monday, 12 January 2015 22:45:22 UTC
> On Jan 12, 2015, at 5:16 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > > On Sun, Jan 11, 2015 at 9:13 PM, Domenic Denicola <d@domenic.me> wrote: >> However, I don't understand how to make it work for upgraded elements at all > > Yes, upgrading is the problem. There's two strategies as far as I can > tell to maintain a sane class design: > > 1) There is no upgrading. We synchronously invoke the correct > constructor. I've been trying to figure out the drawbacks, but I can't > find the set of mutation events problems that relates to this. One > obvious drawback is needing to have all the code in place so you might > need a way to delay the parser (return of synchronous <script> > loading). > > 2) As you indicate, upgrading becomes replacing. This used to be the > old model and got eventually killed through > https://www.w3.org/Bugs/Public/show_bug.cgi?id=21063 though there's no > clear summary as to why that happened. Issues seem to be: mutation > observer spam, dangling references, attributes, event listeners. As we have repeatedly stated elsewhere in the mailing list, we support option 1 since authors and frameworks can trivially implement 2 or choose to set "prototype" without us baking the feature into the platform. - R. Niwa
Received on Monday, 12 January 2015 22:45:22 UTC