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

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

--- Comment #12 from Dimitri Glazkov <dglazkov@chromium.org> ---
(In reply to comment #10)
> Here is a proposal:
> 
> Rename some of the callbacks to better reflect their purpose. readyCallback
> => createdCallback, insertedCallback => enteredDocumentCallback,
> removedCallback => leftDocumentCallback. (attributeChangedCallback remains
> as-is.)

Let's file this as a separate bug.

> 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.

Ditto.

> 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.

This is already the case in the spec, right?

https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#dfn-element-upgrade-algorithm

> 
> 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.

But... the new value might not be the value that _was_ the new value at the
time the callback was queued?

> 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.

+1

> 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.

+1

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

My gut feeling is that the callback ordering is the first order of business
(and the topic of the bug). Callback naming is mostly cosmetics and can be done
after. We still have several of machinery issues to resolve before then, like
bug 20488.

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

Received on Wednesday, 3 July 2013 15:50:24 UTC