Re: Why can't we just use constructor instead of createdCallback?

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.


Received on Friday, 6 December 2013 06:45:30 UTC