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

*How, as component author, do I ensure that my imperative set up code runs
and modifies my element DOM content before the user sees the un-modified
custom element declared in mark-up? (I'm cheating, since this issue isn't
specific to your <prototype>) *

When you say "...runs before the user sees the unmodified...", what do you
mean? The 'readyCallback' is the *run-once-per-instance* imperative code
associated with a component, and would always run *after *something like
'registeredCallback*', *the *run-once-per-component* imperative
code...unless we are talking about different things? As far as what the
user visually sees, there is an understanding that a render my happen
wherein components are not yet inflated/upgraded - in this instance, the
developer should create some styles to account for the non-upgraded state.
This has been the thinking all along btw.


On Mon, Apr 15, 2013 at 1:46 PM, John J Barton
<johnjbarton@johnjbarton.com>wrote:

> What happens if the construction/initialization of the custom element
> calls one of the element's member functions overridden by code in a
> <prototype>?
>
> How, as component author, do I ensure that my imperative set up code runs
> and modifies my element DOM content before the user sees the un-modified
> custom element declared in mark-up? (I'm cheating, since this issue isn't
> specific to your <prototype>)
>
>
> On Mon, Apr 15, 2013 at 12:39 PM, Scott Miles <sjmiles@google.com> wrote:
>
>> Sorry for beating this horse, because I don't like 'prototype' element
>> anymore than anybody else, but I can't help thinking if there was a way to
>> express a prototype without <script> 98% of this goes away.
>>
>> The parser can generate an object with the correct prototype, we can run
>> init code directly after parsing, there are no 'this' issues or problems
>> associating <element> with <script>.
>>
>> At least somebody explain why this is conceptually wrong.
>>
>>
>> On Mon, Apr 15, 2013 at 11:52 AM, Scott Miles <sjmiles@google.com> wrote:
>>
>>>  > 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>