- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Fri, 10 Jan 2014 00:27:27 -0500
- To: Ryosuke Niwa <rniwa@apple.com>, Erik Arvidsson <arv@chromium.org>
- CC: WebApps WG <public-webapps@w3.org>, Jonas Sicking <jonas@sicking.cc>, "Edward O'Connor" <eoconnor@apple.com>, William Chen <wchen@mozilla.com>
On 1/9/14 10:57 PM, Ryosuke Niwa wrote: >> Given that, we could maybe cheat and in fact do some sort of delayed calling of the constructor of ES6 subclasses of elements. You'd still be able to observe these objects in an "unconstructed" state from the subclass pov, but at least it wouldn't be a security issue in terms of operating on a DOM that's in an inconsistent state from the point of view of privileged code. > > Calling constructors after the tree had been constructed will be an issue because then you could access “unconstructed” nodes via nextSibling, parentNode, etc... Right, I did say that above. Is that really a problem in practice, though? > One idea that came out of our discussion is was to add an additional step in the parser to call constructors on all “pending” elements before they’re being constructed into the DOM tree. Isn't that the bad thing we _don't_ want to do? That is, invoke arbitrary page JS from the middle of the parsing algorithm? > On the other hand, solving this seems to require running some author scripts at the element creation time, at some later time but before the node is inserted into the document. The parser is expected to insert the nodes into the document pretty much immediately after creating them, no? -Boris
Received on Friday, 10 January 2014 05:28:00 UTC