> On Feb 23, 2015, at 6:42 AM, Boris Zbarsky <bzbar...@mit.edu> wrote: > > On 2/23/15 4:27 AM, Anne van Kesteren wrote: > >> 1) If we run the constructor synchronously, even during cloning. If >> the constructor did something unexpected, is that actually >> problematic? It is not immediately clear to me what invariants we >> might want to preserve. Possibly it's just that the code would get >> more complicated when not self-hosted? Similar to mutation events? If >> someone has a list of reasons in mind that would be appreciated. This >> type of question keeps popping up. > > So these are the things that come to mind offhand for me, which may or may > not be problems: > > 1) If cloning can have sync side-effects, then we need to either accept that > cloneNode can go into an infinite loop or ... I'm not sure what. And yes, > non-self-hosted implementation gets more complicated. > > 2) There are various non-obvious cloning operations UAs can perform right > now because cloning is side-effect free. For example, when you print Gecko > clones the document and then does the printing stuff async on the cloned > document instead of blocking the UI thread while the (fairly long-running) > print operation completes. If cloning became observable, we'd need to figure > out what to do here internally (e.g. introduce a new sort of cloning that > doesn't run the constructors?).
It seems like this would be an issue regardless of whether callbacks are synchronous or not. Because even if created callback/constructor were to run asynchronously, it would still be observable. In that regard, perhaps what we need another option (although 4 might be a developer friendly superset of this): 5) Don't do anything. Custom elements will be broken upon cloning if there are internal states other than attributes just like cloning a canvas element will lose its context. - R. Niwa
