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

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

Dominic Cooney <dominicc@chromium.org> changed:

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

--- Comment #9 from Dominic Cooney <dominicc@chromium.org> ---
I was talking to myself on bug 22288 about this issue, but let me join the
party.

Given takeRecords, the motivation for this is not expanding basic capability
but improving developer ergonomics.

Here is my proposal:

We go through DOM spec and HTML spec and come up with a set of tree-mutating
operations and attributes:

prepend, append, before, after, replace, remove, insertBefore, appendChild,
replaceChild, removeChild, setAttribute, setAttributeNS, removeAttribute,
removeAttributeNS, innerHTML, textContent and reflected attributes

(Did I miss some? What about DOMTokenList/DOMSettableTokenList?)

Custom Elements legislates an additional step at the end of these to invoke
lifecycle callbacks (without the microtask recursion flag check. You want
consistent behavior when your script is running in a top-level script or in a
lifecycle callback--imagine populating one custom element's shadow DOM with
other custom elements--that will be happening in the readyCallback.)

Implementers want to avoid recreating Mutation Events. I believe that the three
critical differences between Mutation Events to what I'm proposing, which
avoids the problems with Mutation Events, are:

1. The callbacks are queued while the user agent is affecting changes to the
DOM. They are not invoked synchronously on various callstacks deep in the
implementation.

2. The callbacks are invoked when the user agent is about to run script anyway.
Hence if we believe takeRecords is safe (we do) then this is also OK.

3. We're particularly hands-off when it comes to modifications by the parsing
the document. Those happen at microtask checkpoint just like a Mutation
Observeration. I'm not proposing any change wrt lifecycle callbacks and
document parsing.

Through 1+2 this proposal avoids significant reentrancy. This was the main root
cause of many problems with Mutation Events from the implementer's point of
view. Through 3 it avoids running scripts in new places, which was another
concern I heard from implementers.

There is a crude implementation of this in Blink. We have an IDL extended
attribute we stick on methods that we want to do this extra lifecycle callback
processing step before returning.

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

Received on Friday, 7 June 2013 00:01:36 UTC