- From: Scott Miles <sjmiles@google.com>
- Date: Mon, 15 Apr 2013 14:38:48 -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: <CAHbmOLZdCoqwDKNCwaoDBFeaxeFeEX1vy9TCsey8xRCkPmq4_g@mail.gmail.com>
>> So we can override some methods but not others, depending on the implementation? You can override methods that will be called from JS, but not from C++ (depending on platform). >> Gee, that's not very encouraging I was trying to just say we have been aware of these issue too and there are efforts going on here. We are already building apps on these techniques and are exploring these issues with developers. I'd rather not get into all those issues too on this thread. Rather, for the hard-core platform peeps here, I'd prefer to focus on some semantics for document.register and <element> that doesn't cause hives (see what I did there?). Scott 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 21:39:18 UTC