- From: John J Barton <johnjbarton@johnjbarton.com>
- Date: Mon, 15 Apr 2013 13:46:33 -0700
- To: Scott Miles <sjmiles@google.com>
- Cc: William Chen <wchen@mozilla.com>, Rafael Weinstein <rafaelw@google.com>, Daniel Buchner <daniel@mozilla.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: <CAFAtnWwfEAS5Ms1ZM+Jc9mfR1tpd8FV8cNSt7iKcf=+U5cJkwA@mail.gmail.com>
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 20:47:01 UTC