Re: Custom elements: synchronous constructors and cloning
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 wrote: > > > On Tue, Feb 24, 2015 at 7:37 AM, Anne van Kesteren > wrote: > >> On Tue, Feb 24, 2015 at 4:35 PM, Dimitri Glazkov >> 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
On Tue, Feb 24, 2015 at 7:37 AM, Anne van Kesteren wrote: > On Tue, Feb 24, 2015 at 4:35 PM, Dimitri Glazkov > 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
On Tue, Feb 24, 2015 at 4:35 PM, Dimitri Glazkov 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
On Tue, Feb 24, 2015 at 12:14 AM, Anne van Kesteren wrote: > On Mon, Feb 23, 2015 at 11:58 PM, Ryosuke Niwa 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
On Mon, Feb 23, 2015 at 11:58 PM, Ryosuke Niwa 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... -- https://annevankesteren.nl/
Re: Custom elements: synchronous constructors and cloning
> On Feb 23, 2015, at 6:42 AM, Boris Zbarsky 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
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
