[Bug 21969] [Custom]: add attributeChangedCallback to the set of prototype callbacks

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

Rafael Weinstein <rafaelw@chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rafaelw@chromium.org

--- Comment #7 from Rafael Weinstein <rafaelw@chromium.org> ---
So I agree with Olli here,

For attributeChanged, I think that (new
MutationObserver(callback)).observe({attributes: true}); is pretty
straightforward.

Ideally, we'd re-use existing primitives where possible, unless they fall down.

WRT the desire for sync behavior, remember that a MutationObserver can
takeRecords() and thus *can* present a sync API boundary.

I realize that this is more difficult, but I believe that the concerns with
Mutation Events apply to this case (as they do in general).

Imagine that you end up with an app with lots of custom elements and someone
changes an attribute. It's not hard to imagine that that custom element will
react to that change by changing another attribute on itself or another
element.

Thus you get right back into the quagmire of

-Sync events potentially lying about what happened (by the time you hear about
something, someone else has changed it more -- or un-done it)
-No event listener gets to act in insolation (he can be prempted by another
listener)
-Event listeners having to implement brittle, terrible hacks to *ignore* the
effects of their *own* changes (which is trivially accomplished with
MutationObservers).

The siren song of sync mutation events calls once again, and we should avoid
it's pitfalls if at all possible.

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

Received on Thursday, 6 June 2013 16:40:42 UTC