W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2015

Custom elements: synchronous constructors and cloning

From: Anne van Kesteren <annevk@annevk.nl>
Date: Mon, 23 Feb 2015 10:27:45 +0100
Message-ID: <CADnb78gpUytP_dfS-T=iXfTga_m9kb208upH3rGYnirduazWvA@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:25 UTC