[Bug 22459] [Custom]: Consider explicitly emptying callback queue in more cases

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22459

--- Comment #10 from Dominic Cooney <dominicc@chromium.org> ---
Here is a proposal:

Rename some of the callbacks to better reflect their purpose. readyCallback =>
createdCallback, insertedCallback => enteredDocumentCallback, removedCallback
=> leftDocumentCallback. (attributeChangedCallback remains as-is.)

Bring __proto__ swizzling, the applicability of :unresolved, and invoking the
createdCallback together so that they occur at the same point in time. This
means the custom element author can treat the createdCallback like a
constructor and does not have to deal with handling calls on the prototype
before createdCallback gets a chance to run. Authors can rely on prototype
instanceof checks, querySelector with :unresolved/:not(:unresolved), and having
run the constructor giving consistent results.

When the createdCallback returns, if the element is in the document, the
enteredDocumentCallback must be called at that point. This means authors can
assume that their elements are created outside of the document, then added to
it, and keep any "in document" handling in the enteredDocumentCallback and not
blur it into createdCallback.

The attributeChanged callback is more specifically typed as

callback void (DOMString name, DOMString oldValue);

When the attribute is being added, the oldValue is null. Authors can use
getAttribute to retrieve the new value. Other cases: These arguments get
exactly what you'd expect.

Instead of specifying a set of methods where callbacks are processed, specify
that callbacks are processed at *every* method. It is a readily available
optimization for browser vendors to only process callbacks at methods which may
schedule callbacks.

Lastly, the queue of callbacks should become more elaborate to support
recursion better. There is no recursion guard. Instead of a global queue of
callbacks, each element has a local queue of callbacks pertaining just to that
element. As script calls into DOM, a callback scope is pushed onto the stack.
As a callback is scheduled with an element, the *element* is noted in the
callback scope. When the callback scope exits (ie right before returning to
script), the elements are processed; "processing" an element means invoking the
callbacks in its queue. Note that there is a queue *per element*, not *per
element, scope pair.* Processing a given element's queue may be resumed in the
case of recursion.

I plan to implement this in Blink to get feedback from web developers.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 3 July 2013 03:14:18 UTC