- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Mon, 23 Feb 2015 10:27:45 +0100
- To: WebApps WG <public-webapps@w3.org>
- Cc: Yehuda Katz <wycats@gmail.com>, Boris Zbarsky <bzbarsky@mit.edu>, Ryosuke Niwa <rniwa@apple.com>
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/
Received on Monday, 23 February 2015 09:28:13 UTC