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

On Mon, Apr 15, 2013 at 11:29 AM, Scott Miles <sjmiles@google.com> wrote:

> Thank you for your patience. :)
>
ditto.

>
>

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

I think the Pinocchio link makes the case that you have only three choices:
   1) call 'init' when component instance tag is encountered, blocking
parsing,
   2) call 'init' later, causing reflows and losing the value of not
blocking parsing,
   3) don't allow 'init' at all, limiting components.

So "non-starter" is just a vote against one of three Bad choices as far as
I can tell. In other words, these are all non-starters ;-).


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

Indeed, however the relative order of the component's script tag processing
and the component's tag <element> is all I was talking about.


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