Re: Custom elements: synchronous constructors and cloning
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
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
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
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
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
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
Custom elements: synchronous constructors and cloning
I've been continuing to explore synchronous constructors for custom elements as they explain the parser best. After reading through https://speakerdeck.com/vjeux/oscon-react-architecture I thought there might be a performance concern, but Yehuda tells me that innerHTML being faster than DOM methods is no longer true. Dimitri pointed out that cloning might be problematic. The https://dom.spec.whatwg.org/#concept-node-clone operation is invoked from numerous range operations that might not expect side effects. Here are the alternatives to consider: 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. 2) When running the constructor DOM methods that cause mutations throw. They are locked. This might not work well due to shadow DOM. 3) We use structured cloning. Custom state stored behind an Element.state symbol. 4) We use structured cloning, but for custom state a callback is invoked with similar timing to the callbacks part of custom elements today. Both 3 and 4 seem the least invasive to the current state of play, but it would be good to know why we want to preserve the status quo for 1 and 2. -- https://annevankesteren.nl/
