Re: Replacement for mutation events

On 02/02/11 11:01, Olli Pettay wrote:
> Hi all,
> 
> I'm hoping we could prototype Jonas' proposal in Gecko
> pretty soon (using moz prefix of course!). It should be very easy to
> implement. The method names in the proposal could need still some tweaking.
> Maybe there could be just two methods
> addMutationObserver(SOME_CONSTANT, callback_function)
> removeMutationObserver(SOME_CONSTANT, callback_function)

Looking at the current list it looks like we should have an argument for
"just this node" or "any node in this tree".  That would get rid of 4
out of the 10 methods and seems more clear to me.

Why does this proposal try to make the notifications synchronous?  This
is only important when the code that performed the mutation is relying
on the actions of the notification.  If the author of the code is
relying on the notifications to do something they must know that
something needs to be done, and can therefore make the relevant calls
directly in ECMAScript.

It feels neater to me to have the notifications always be async.  If the
notifications are occasionally async this might be confusing for
authors, and is more awkward to implement.

> I'm worried about the performance of selector based
> proposals.  You would need to run selector (after timeout)
> whenever something in DOM tree changes, but also whenever some
> state changes (hover, focus, etc). That would mean *lots* of
> calls to querySelectorAll.
> Also, the selector based proposals need a separate method for
> changes in characterdata, like watchCharacterData.
> That just feels a bit hacky to me.

Agreed.

-- 
Andrew Oakley

Received on Wednesday, 2 February 2011 12:09:07 UTC