On Mon, Apr 15, 2013 at 2:01 PM, Scott Miles <sjmi...@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 < > johnjbar...@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 <sjmi...@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 <sjmi...@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 < >>>> johnjbar...@johnjbarton.com> wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Mon, Apr 15, 2013 at 11:29 AM, Scott Miles <sjmi...@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 < >>>>>> johnjbar...@johnjbarton.com> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Apr 15, 2013 at 10:38 AM, Scott Miles <sjmi...@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 < >>>>>>>> johnjbar...@johnjbarton.com> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Apr 15, 2013 at 9:44 AM, Scott Miles >>>>>>>>> <sjmi...@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" <sjmi...@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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >