Re: Custom elements: synchronous constructors and cloning

> On Feb 23, 2015, at 6:42 AM, Boris Zbarsky <bzbarsky@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

Received on Monday, 23 February 2015 22:58:57 UTC