- From: John J Barton <johnjbarton@johnjbarton.com>
- Date: Mon, 15 Apr 2013 15:33:34 -0700
- To: Daniel Buchner <daniel@mozilla.com>
- Cc: Scott Miles <sjmiles@google.com>, William Chen <wchen@mozilla.com>, Rafael Weinstein <rafaelw@google.com>, Rick Waldron <waldron.rick@gmail.com>, Dave Herman <dherman@mozilla.com>, Allen Wirfs-Brock <allen@wirfs-brock.com>, Boris Zbarsky <bzbarsky@mit.edu>, Jonas Sicking <jonas@sicking.cc>, Blake Kaplan <mrbkap@mozilla.com>, public-webapps <public-webapps@w3.org>, Steve Orvell <sorvell@google.com>, Dimitri Glazkov <dglazkov@google.com>
- Message-ID: <CAFAtnWxRWg1de9hRykBPGvfB5P6gemqA0RmvHy68NK9ATkcdgA@mail.gmail.com>
I think that rendering a placeholder (eg blank image) then filling it in rather than blocking is good if done well (eg images with pre-allocated space). Otherwise it's bad but less bad than blocking ;-). But if you allow this implementation, then this whole discussion confuses me even more. I'm thinking: "If you don't need the custom constructors during parsing, just wait for them to arrive, then call them." Something else is going on I suppose, so I'm just wasting your time. On Mon, Apr 15, 2013 at 2:42 PM, Daniel Buchner <daniel@mozilla.com> wrote: > * > * > *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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
Received on Monday, 15 April 2013 22:34:03 UTC