Re: [webcomponents]: Of weird script elements and Benadryl

Thank you for your patience. :)

> ? user's instance code?  Do you mean: Running component instance
initialization during document construction is Bad?

My 'x-foo' has an 'init' method that I wrote that has to execute before the
instance is fully 'constructed'. Parser encounters an <x-foo></x-foo> and
constructs it. My understanding is that calling 'init' from the parser at
that point is a non-starter.

> But my original question concerns blocking component documents on their
own <script> tag compilation. Maybe I misunderstood.

I don't think imports (nee component documents) have any different
semantics from the main document in this regard. The import document may
have an <x-foo> instance in it's markup, and <element> tags or <link
rel="import"> just like the main document.


On Mon, Apr 15, 2013 at 11:23 AM, John J Barton <johnjbarton@johnjbarton.com
> wrote:

>
>
>
> 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
>>>
>>>
>>>
>>>
>>>
>>
>