On Mon, Apr 15, 2013 at 10:38 AM, Scott Miles <sjmiles@google.com> wrote:
> Dimitri is trying to avoid 'block[ing] instance construction' because
> instances can be in the main document markup.
>
Yes we sure hope so!
>
> 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.
>
Sure.
>
>
> 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'.
>
? user's instance code? Do you mean: Running component instance
initialization during document construction is Bad?
>
> 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.)
>
You must block creating instances of components until component documents
are parsed and initialized. Because of limitations in HTML DOM
construction, you may have to block HTML parsing until instances of
components are created. Thus I imagine that creating instances may block
HTML parsing until component documents are parsed and initialized or the
HTML parsing must have two passes as your Pinocchio link outlines.
But my original question concerns blocking component documents on their own
<script> tag compilation. Maybe I misunderstood.
jjb
>
>
>
> 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
>>
>>
>>
>>
>>
>