- From: Scott Miles <sjmiles@google.com>
- Date: Mon, 15 Apr 2013 12:39:57 -0700
- To: John J Barton <johnjbarton@johnjbarton.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: <CAHbmOLa5EgqoX+2zU9kjvKRFKJu4e_bJ-+WVWYj7tY+Z7YVRmg@mail.gmail.com>
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 19:40:26 UTC