Dimitri is trying to avoid 'block[ing] instance construction' because
instances can be in the main document markup.
The main document can have a bunch of markup for custom elements. If the
user has made element definitions a-priori to parsing that markup
(including inside <link rel='import'), he expects those nodes to be 'born'
correctly.
Sidebar: running user's instance code while the parser is constructing the
tree is Bad(tm) so we already have deferred init code until immediately
after the parsing step. This is why I keep saying 'ready-time' is different
from 'construct-time'.
Today, I don't see how we can construct a custom element with the right
prototype at parse-time without blocking on imported scripts (which is
another side-effect of using script execution for defining prototype, btw.)
If we don't block, the parser has to construct some kind of place holder
for each custom instance, and then we upgrade them in a second pass.
On Mon, Apr 15, 2013 at 9:54 AM, John J Barton
<johnjbarton@johnjbarton.com>wrote:
>
>
>
> On Mon, Apr 15, 2013 at 9:44 AM, Scott Miles <sjmiles@google.com> wrote:
>
>> >> Why do the constructors of component instances run during component
>> loading?
>>
>> I'm not sure what you are referring to. What does 'component loading'
>> mean?
>>
>> >> Why not use standard events rather than callbacks?
>>
>>
>> I'll some of the doc you link below and re-ask.
>
>> On Apr 15, 2013 9:04 AM, "Scott Miles" <sjmiles@google.com> wrote:
>>>
>>>> Again, 'readyCallback' exists because it's a Bad Idea to run user code
>>>> during parsing (tree construction). Ready-time is not the same as
>>>> construct-time.
>>>>
>>>> This is the Pinocchio problem:
>>>> http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0728.html
>>>>
>>>>
> -------
>
> 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.
>
> ----
>
> Why do the constructors of component *instances* which don't need to run until instances are created, need to block the load of component documents?
>
> Seems to me that you could dictate that <script> in components load async WRT components but block instance construction.
>
> jjb
>
>
>
>
>