Re: Custom elements: synchronous constructors and cloning

2015-02-24 Thread Anne van Kesteren
On Tue, Feb 24, 2015 at 4:35 PM, Dimitri Glazkov dglaz...@google.com wrote:
 Wait, what do you mean by that is what custom elements provide for today..

 The entire pattern of template-stamping depends on the fact that custom
 elements aren't broken when cloning/importing.

There's no hook for cloning, is there? Or is the created callback
supposed to be invoked? (If it is, that's missing from the
specification.)


-- 
https://annevankesteren.nl/



Re: Custom elements: synchronous constructors and cloning

2015-02-24 Thread Dimitri Glazkov
On Tue, Feb 24, 2015 at 12:14 AM, Anne van Kesteren ann...@annevk.nl
wrote:

 On Mon, Feb 23, 2015 at 11:58 PM, Ryosuke Niwa rn...@apple.com wrote:
  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.

 Putting state in a known place as with 3 also seems okay. Although if
 anything throws there you would have to catch and ignore it. But yes,
 perhaps 5 is a good start as that is what custom elements provide for
 today...


Wait, what do you mean by that is what custom elements provide for today..

The entire pattern of template-stamping depends on the fact that custom
elements aren't broken when cloning/importing.

:DG


Re: Custom elements: synchronous constructors and cloning

2015-02-24 Thread Dimitri Glazkov
Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=28092 to add more data
to the informative content around the normative statement that makes this
happen.

On Tue, Feb 24, 2015 at 7:39 AM, Dimitri Glazkov dglaz...@google.com
wrote:



 On Tue, Feb 24, 2015 at 7:37 AM, Anne van Kesteren ann...@annevk.nl
 wrote:

 On Tue, Feb 24, 2015 at 4:35 PM, Dimitri Glazkov dglaz...@google.com
 wrote:
  Wait, what do you mean by that is what custom elements provide for
 today..
 
  The entire pattern of template-stamping depends on the fact that custom
  elements aren't broken when cloning/importing.

 There's no hook for cloning, is there? Or is the created callback
 supposed to be invoked? (If it is, that's missing from the
 specification.)


 There's no special hook for cloning, no. But the created callback is
 definitely invoked when cloning. The spec simply says that it's queued
 whenever an element is created.




 --
 https://annevankesteren.nl/





Re: Custom elements: synchronous constructors and cloning

2015-02-24 Thread Dimitri Glazkov
On Tue, Feb 24, 2015 at 7:37 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Tue, Feb 24, 2015 at 4:35 PM, Dimitri Glazkov dglaz...@google.com
 wrote:
  Wait, what do you mean by that is what custom elements provide for
 today..
 
  The entire pattern of template-stamping depends on the fact that custom
  elements aren't broken when cloning/importing.

 There's no hook for cloning, is there? Or is the created callback
 supposed to be invoked? (If it is, that's missing from the
 specification.)


There's no special hook for cloning, no. But the created callback is
definitely invoked when cloning. The spec simply says that it's queued
whenever an element is created.




 --
 https://annevankesteren.nl/



Re: Custom elements: synchronous constructors and cloning

2015-02-23 Thread Boris Zbarsky

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



Re: Custom elements: synchronous constructors and cloning

2015-02-23 Thread Ryosuke Niwa

 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