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

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

--- Comment #11 from Daniel Buchner <danieljb2@gmail.com> ---
(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.)

Not sure the callback names need to be more verbose, I'll posit this isn't a
novice API folks will happen upon, thus the 2 second thought/look-up on MDN or
Web Platform docs are not much of a hurdle. I would stay away from churning
anything at this level, it just isn't worth it, IMO of course. (FWIW, I always
liked create vs ready, but in the end, it probably doesn't matter)

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

Makes sense to me.

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

1) I'm not sure if there's any empirical reason not to just pass the new value
(certainly not speed/perf right?) 2) Are those the "arguments you'd expect"?
How do we know this, and why is another arg so 'unexpected'?

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

Received on Wednesday, 3 July 2013 15:39:16 UTC