Re: Mutation events replacement

Giovanni Campagna wrote:
>>> In that case, we may need something like .startTransaction() and
>>> .endTransaction()

I would be strongly opposed to that, because authors are notoriously bad 
about doing things like endTransaction().  If we could have a syntax 
that automatically ended the transaction on exit from the current stack 
frame I would be happier with it.  But even then, I'm not sure it's 
worth it.

> 1) I set an attribute, the listener fires
> I set the attribute again back to the previous value, the listener fires again
> In that case, I may want to ignore the listener completely, because
> the attribute didn't really change.

You may, but you may not; it depends on what the listener is doing. 
This seems like it should be under the control of the listener, not the 
mutator.

> 2) I have a long list of element that I want to add to another one.
> Every appendChild() will trigger the modification listener, again and again.
> In this case, I may want to use the "batch" feature, and call it just
> once, in particular if the listener is watching only for the elements
> present under the subtree, rather than the modification itself.

Put all the elements in a DocumentFragment and insert it as a single 
operation?  Right now UAs fire multiple mutation events in that 
situation, but I would be ecstatic if that were not the case.

> 3) I'm sure there is code that expects (or requires) that after a
> "setAttribute" the only thing that changed in the DOM was the actual
> attribute set.

This code will already be broken by all sorts of other technologies 
under development (XBL2 comes to mind)....

> Preventing modification listeners within "protected" code helps this.

At the cost of greatly increased complexity for everyone, though.  Is 
there actually much demand for this, to the point where code that 
doesn't need this needs to be burdened with dealing with this 
"protected" business?

>> 1. Listeners should be notified in the order that mutations take
>> place.
> It makes a lot of sense, sure. Just I find more intuitive the
> reentrant behavior (modifications use local list), and I think that
> both are possible and have some advantages.
> Actually, I haven't understood yet why feature 1) is so important.

Without the above property 1, even something as simple as keeping track 
of "is the node in the DOM?" becomes impossible: if it's removed and 
reinserted you can get the insertion notification before the removal.

Which means that any system that doesn't have the property is 
effectively equivalent, in terms of what you can rely on from it, to a 
system which every so often dispatches notifications with no more 
information than "something changed".

If we want such a system, fine, but then let's design it that way 
instead if having a bunch of complexity like DOM events do.

-Boris

Received on Saturday, 6 June 2009 18:11:04 UTC