Re: Mutation events replacement

2009/6/6 Boris Zbarsky <bzbarsky@mit.edu>:
> 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.

Well, we may say that going back to native code implies a call to
endTransaction, similar to the behaviour of getStorageUpdates in HTML5

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

On the control of the listener, the mutator or both. My proposal
allows both of this.

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

Not everything can be inserted in a DocumentFragment (attributes for
example cannot), and DocumentFragment works only for children of one
element.

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

That's true.

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

It is not increased, because I expect that internally the UAs will do
a startTransaction at the begin of a innerHTML and endTransaction at
the end. The same with DocumentFragment, execCommand, drag and drop,
etc.
I just proposed to give the authors this APIs

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

Well, modifications express actions, not states, so it could be a
design choice to fire insertion before removal, if insertion was part
of the removal (inside the removal handler), but I agree that probably
property 1 is more useful.

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

Well, these are very similar to DOM events, just they're target and bubble only.

> -Boris
>

Giovanni

Received on Saturday, 6 June 2009 19:23:16 UTC