It seems to me like you might be trying to solve a set of contradictory requirements:
1. We want to enable implementing existing "complex" elements using WebComponents 2. Running scripts in the middle of parsing is unsafe. 3. Exiting parsing for any "complex" element is slow. 4. We don't want to be unsafe or slow. The advantage that built-in code is always going to have over code provided by a page is that built-in code can be trusted to not attempt to hack the browser. So I simply don't think there is a way to enable implementing existing complex elements using WebComponents without making some type of exceptions for built-in implementations. I.e. you could still use webcomponents to implement complex elements, but you'd have to give them additional powers. For example in the form of being able to run constructors (and maybe attribute mutation handlers) synchronously. / Jonas On Fri, Mar 8, 2013 at 11:27 AM, Dimitri Glazkov <dglaz...@google.com> wrote: > 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< >
