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

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

IMO, the not-yet-upgraded case is nothing new, and developers will hardly
be surprised. This nit is no different than if devs include a jQuery plugin
script at the bottom of the body that 'upgrades' various elements on the
page after render - basically, it's an unfortunate case of That's Just Life™


Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation


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

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