W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: [webcomponents]: Custom element constructors are pinocchios

From: Scott Miles <sjmiles@google.com>
Date: Fri, 8 Mar 2013 12:00:39 -0800
Message-ID: <CAHbmOLauRx+mzXie9BWDXjq-=RZONyiPcg_+2XqRoGco1-RYZQ@mail.gmail.com>
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>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:58 GMT