- From: Dimitri Glazkov <dglazkov@google.com>
- Date: Thu, 14 Feb 2013 15:03:36 -0800
- To: Scott Miles <sjmiles@google.com>
- Cc: Daniel Buchner <daniel@mozilla.com>, Rick Waldron <waldron.rick@gmail.com>, Erik Arvidsson <arv@chromium.org>, public-webapps <public-webapps@w3.org>, Boris Zbarsky <bzbarsky@mit.edu>, Anne van Kesteren <annevk@annevk.nl>
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:04:07 UTC