Re: Mutation events replacement

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

Could you elaborate better on the weird behaviour?

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

I mentioned them previously:
1) avoiding multiple listener calls for changes that are immediately reverted
2) avoiding potentially unexpected DOM changes
3) batching multiple DOM changes in few calls

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

The whole purpose of this topic is to make mutation notification
collapse whenever it is possibile, including for attributes (for
example as the result of an execCommand)

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

Authors are not required to use this API, so it is not more complex.
Advanced authors, that can understand the subtle implications of
start/endTransation, will use it, while the others will not, or will
use predefined libraries.

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

In that case the usefulness of mutation events would have been largely
reduced (the application has to do something in response to mutation
events)

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

Modification Notifications, ie Jonas Sicking's proposal at the
beginning of this thread.

> -Boris
>

Giovanni

Received on Sunday, 7 June 2009 12:29:45 UTC