- From: Daniel Buchner <daniel@mozilla.com>
- Date: Mon, 15 Apr 2013 16:58:56 -0700
- To: John J Barton <johnjbarton@johnjbarton.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: <CAHZ6zJF3Agt01e2HgLoY-ET8x21XpOMKsaDwkvoqZoDibg4GEw@mail.gmail.com>
Would this be possible using the Scott and Brendan's idea of using a specific element for prototyping? --> https://gist.github.com/csuwldcat/5392291 On Mon, Apr 15, 2013 at 3:33 PM, John J Barton <johnjbarton@johnjbarton.com>wrote: > 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 23:59:56 UTC