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

 > 1) call 'init' when component instance tag is encountered, blocking
parsing,

Fwiw, it was said that calling user code from inside the Parser could
cause Armageddon, not just block the parser. I don't recall the details,
unfortunately.


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

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