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

On Mon, Apr 15, 2013 at 2:01 PM, Scott Miles <sjmiles@google.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>?
>
> IIRC it's not possible to override methods that will be called from inside
> of builtins, so I don't believe this is an issue (unless we change the
> playfield).
>

Ugh. So we can override some methods but not others, depending on the
implementation?

So really these methods are more like callbacks with a funky kind of
registration. It's not like inheriting and overriding, it's like onLoad
implemented with an inheritance-like wording.  An API users doesn't "think
like an object", rather they ask the Internet some HowTo questions and get
a recipe for a particular function "override".

Ok, I'm exaggerating, but I still think the emphasis on inheritance in the
face of so me is a high tax on this problem.



>
> >> 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>)
>
> This is another can of worms. Right now we blanket solve this by waiting
> for an 'all clear' event (also being discussed, 'DOMComponentsReady' or
> something) and handling this appropriately for our application.
>

Gee, that's not very encouraging: this is the most important kind of issue
for a developer, more so than whether the API is inheritance-like or not.



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