On Dec 5, 2013, at 10:44 PM, Boris Zbarsky <[email protected]> wrote: > 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.
Then how do we define a custom element using ES6 classes? Are we going to not call the constructor? - R. Niwa
