Re: Mutation events replacement

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

We could, but that leads to weird behavior where a library might do 
something that confuses the script using it.... or vice versa.  It's a 
very fragile setup.

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

I guess it sounds to me like your proposal introduced a lot of 
complexity and fragility without much benefit (from my point of 
view)....  What are the use cases, exactly?

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

It's not clear how one would coalesce the mutation notifications for 
those cases, though.  For the case you were talking about, where the 
coalescing is obvious, it's already available.  The number of pages out 
there using it is approximately 0....

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

There are lots of things the UA does or can do that I don't trust for 
authors to do.  And the complexity is in the exposed programming model 
for script, not for the UA.  Implementing your proposal would not be 
that bad from a UA perspective.  I just happen to think it's harmful to 
do so.

>>>> 1. Listeners should be notified in the order that mutations take
>>>> place.
...
>> 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.
> 
> 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)

Yes, but the removal handler fires before the removal...  Now this 
design choice you describe was in fact made in the design of DOM events, 
largely because the authors of that spec went with the whole "mutation 
handlers should not modify the DOM" wishy-washiness instead of what I 
think would have made sense given the general design of DOM events: 
attempts to modify the DOM from inside a mutation handler throw.

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

Which "these"?

-Boris

Received on Saturday, 6 June 2009 22:34:45 UTC