Re: Custom elements: synchronous constructors and cloning

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?).

3)  As you note, we'd need to figure out what to do with current clone 
consumers.  This includes not just range stuff but things built on top 
of said range stuff or on top of cloning directly.  Things like editing 
functionality, for example.  Not that we have a real spec for that 
anyway....

-Boris

Received on Monday, 23 February 2015 14:42:51 UTC