Ok. Yes, I think we are actually agreeing (even though you said I had it backwards, lol). All I meant to say was that the fact that we can't call HTMLButtonElement is not a practical problem because we have no need to call it. On Thu, Feb 14, 2013 at 3:03 PM, Dimitri Glazkov <dglazkov@google.com>wrote: > On Thu, Feb 14, 2013 at 2:47 PM, Scott Miles <sjmiles@google.com> wrote: > > Developer cannot call HTMLButtonElement. So whatever work it represents > that > > MUST be done by the browser. > > Right. I think we're agreeing, but using different words. An instance > of an HTMLButtonElement-derived element consists of two steps: > > 1) Instantiate a platform object (that's where the C++ object's > constructor is called) > 2) Create a corresponding JS object (that's where the JS object's > constructor is called) > > Most of the time, these happen one right after another, except when > the renderer is parsing HTML. The parser can't stop and let user code > run at any given time (again, a design limitation we have to live with > for a while). So we have to split these steps to happen at different > times: > > a) The C++ step happens as the parser builds the tree > 2) The JS step happens as a microtask after tree's been built. > > Since these are two separate steps, I technically don't _need_ to put > HTMLButtonElement.call(this) into my element's constructor -- it's a > sure bet it will just be a useless dummy. > > This is sad, because the next questions you'll ask will be: > > Dimitri, but what if we built DOM in JS? How would this work then? > Wouldn't "platform object" be just a JS object? Why the heck would we > need this two-step split? > > I don't have good answers. One of them is that we teach developers to > always put dummy HTMLButtonElement.call(this) lines into their element > constructors and future-proof the world like that. > > :DG< >
Received on Thursday, 14 February 2013 23:08:36 UTC