- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Fri, 06 Dec 2013 01:44:56 -0500
- To: public-webapps@w3.org
On 12/6/13 12:03 AM, Ryosuke Niwa wrote: > That sounds like an implementation detail of Blink/WebKit. It seems like a pretty fundamental restriction for all current HTML parsers. In particular, the HTML parsing algorithm has no provisions for script mutating the DOM at random points in the algorithm (in fact, pretty much anywhere other than when <script> elements are inserted). > Also, JS > "wrappers" aren't even constructed immediately for builtin elements in > WebKit and Blink Now _that_ is a WebKit/Blink specific implementation detail (though one shared by other browser engines at the moment). Last I checked, Servo plans to have a single JS object for an element, not separate "actual object" and "JS wrapper" objects. And it seems like we don't want to preclude that sort of implementation strategy, which requires that the ES object be created when the element is created.. > so delaying the construction of elements until later time (e.g. end of micro task) seems fine. End of microtask is not acceptable, unfortunately. It would mean that if you set innerHTML on a node and then try to touch its new kids you get not-yet-constructed objects. :( We could try to invent a new synchronization point for this sort of thing (e.g. similar to Gecko's scriptrunners), but any such setup with delayed construction has a significant failure mode in the innerHTML case: When one of the constructors is running, the other nodes that got inserted are still in a not-constructed state. That doesn't seem great. Which then puts us back to running script while the innerHTML parser is running. Which is also not great. For example it would completely preclude any attempts to parallelize innerHTML parsing. And yes, I know those might be doomed to failure anyway... I can't tell you how you should weight these various drawbacks, obviously. -Boris
Received on Friday, 6 December 2013 06:45:30 UTC