What follows is an attempt to summarize the (relatively recent)
discussions regarding replacing DOM Mutation Events.
My goals here are to:
-Provide a quick primer for those who haven't read all hundred or so emails.
-Reiterate the aspects of a solution which seem to have broad support.
-Identify the main points of divergence which remain.
Problem: DOM Mutation events as currently specified and implemented
are widely viewed as fatally flawed because they are:
(1) Verbose (fire too often)
(2) Slow (because of event propagation -- and because they prevent
certain UA run-time optimizations)
(3) "Crashy" (have been the source of many crashers for UAs because
script can tear up the world in any way it wishes while a DOM
operation is underway).
Solution:
*Agreed upon design points:
Primarily because of a proposal made by Jonas Sicking in 2009, the
group has been largely in agreement about the following:
(1) The vocabulary of mutations should be more expressive and require
fewer "words" to adequately describe what happened . For instance, a
single innerHTML assignment which results in removing N nodes and
inserting M nodes should be expressed as a single mutation (e.g. {
mutation: "ChildlistChanged", added: [...], removed: [...] } ) -- not
a sequence of mutations, one for each node inserted or removed.
(2) Mutations should avoid the expense of event propagation (mainly
capture & bubble).
(3) Mutations should be delivered to observers after the DOM
operations which generated them complete -- removing the possibility
of having script interfere with their operation. For example, an
execCommand() operation is permitted to make any & all DOM operations
it needs *before* it has to notify any observers of what happened.
Through discussing Jonas's proposal, we observed that in a system
which allows multiple observers that can, themselves, make mutations,
observers will generally need to be tolerant of an arbitrary number of
mutations having occurred before being notified.
Further, there is strong performance motivation for observers to
respond to the net-effect of a set of mutations, rather than acting
immediately in response to each mutation.
Thus:
(4) Observers should be called with the *set* of mutations which has
occurred since they were last called (or since registration), rather
than being called once per mutation. I.e. Deliver mutations in batches
of "everything that has happened since the last time I called you -
up till now".
To my understanding, the most recent proposals made by Jonas, Olli
Pettay, Adam Klein and myself all agree on the above four design
points.
*Design points lacking consensus:
(5) When are mutations delivered? There are four options here, only
two of which have proponents.
=>I'm going to try to summarize the discussion on this point in a
separate email.
(6) The semantics for expressing interest in sets of nodes
(7) What information is contained in mutation records
=>I've done a survey of the main use cases sited and prototyped the
main "net-effect projections". I'll summarize my findings in another
email which attempts to layout the main trade-offs I see so far.
