Re: Mutation events replacement

Giovanni Campagna wrote:
>> 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?

If some script does a mutation and expects an event to fire as a result 
but someone up the callstack has started an event batch, the code won't 
get the events it expects.

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

Yes, but why?  Is this common?

> 2) avoiding potentially unexpected DOM changes

OK, this one is somewhat compelling.

> 3) batching multiple DOM changes in few calls

I'm not sure why this matters, honestly.

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

Sort of, yes.  Different types of mutations are still not coalesced, are 
they?

> Authors are not required to use this API, so it is not more complex.

They're required to assume whatever libraries they include might use it, 
though....

> Advanced authors, that can understand the subtle implications of
> start/endTransation, will use it, while the others will not, or will
> use predefined libraries.

Likewise, libraries have to assume that the author using the library 
might use it (so they can't rely on synchronous mutation events anymore).

Which really sucks for library authors, I bet.

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

It doesn't have to do it synchronously.


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

They differ in not creating event objects or sticking all sorts of 
information on them, which is the whole point, I believe.

-Boris

Received on Sunday, 7 June 2009 12:56:07 UTC