- From: Dimitri Glazkov <dglazkov@google.com>
- Date: Fri, 8 Mar 2013 11:27:19 -0800
- To: public-webapps <public-webapps@w3.org>
- Cc: Scott Miles <sjmiles@google.com>, Erik Arvidsson <arv@chromium.org>, Boris Zbarsky <bzbarsky@mit.edu>, William Chen <wchen@mozilla.com>, Blake Kaplan <mrbkap@mozilla.com>
As I started work on the components spec, I realized something terrible: a) even if all HTML parsers could run script at any point when constructing tree, and b) even if all JS engines supported overriding [[Construct]] internal method on Function, c) we still can't make custom element constructors run exactly at the time of creating an element in all cases, d) unless we bring back element upgrade. Here's why: i) when we load component document, it blocks scripts just like a stylesheet (http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#a-style-sheet-that-is-blocking-scripts) ii) this is okay, since our constructors are generated (no user code) and most of the tree could be constructed while the component is loaded. iii) However, if we make constructors run at the time of tree construction, the tree construction gets blocked much sooner, which effectively makes component loading synchronous. Which is bad. I see two ways out of this conundrum: 1) Give up on custom element constructors ever meeting the Blue Fairy and becoming real boys, thus making them equivalent to readyCallback Pros: * Now that readyCallback and constructor are the same thing, we could probably avoid a dual-path API in document.register Cons: * constructors are not real (for example, when a constructor runs, the element is already in the tree, with all of the attributes set), so there is no pure instantiation phase for an element 2) resurrect element upgrade Pros: * constructors are real Cons: * rejiggering document tree during upgrades will probably eat all (and then some!) performance benefits of asynchronous load WDYT? :DG<
Received on Friday, 8 March 2013 19:27:52 UTC