- From: Scott Miles <sjmiles@google.com>
- Date: Fri, 8 Mar 2013 12:00:39 -0800
- To: Dimitri Glazkov <dglazkov@google.com>
- Cc: public-webapps <public-webapps@w3.org>, Erik Arvidsson <arv@chromium.org>, Boris Zbarsky <bzbarsky@mit.edu>, William Chen <wchen@mozilla.com>, Blake Kaplan <mrbkap@mozilla.com>
- Message-ID: <CAHbmOLauRx+mzXie9BWDXjq-=RZONyiPcg_+2XqRoGco1-RYZQ@mail.gmail.com>
IMO, there is no benefit to 'real' constructors other than technical purity, which is no joke, but I hate to use that as a club to beat users with. This is strictly anecdotal, but I've played tricks with 'constructor' before (in old Dojo) and there was much hand-wringing about it, but to my knowledge there was never even one bug report (insert grain-of-salt here). The main thing is to try to make sure 'instanceof' is sane. On Fri, Mar 8, 2013 at 11:27 AM, Dimitri Glazkov <dglazkov@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< >
Received on Friday, 8 March 2013 20:01:11 UTC