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 <dglaz...@google.com>wrote:

> On Thu, Feb 14, 2013 at 2:47 PM, Scott Miles <sjmi...@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<

Reply via email to