- From: Andrew Oakley <andrew@ado.is-a-geek.net>
- Date: Wed, 02 Feb 2011 11:50:25 +0000
- To: Olli@pettay.fi
- CC: Olli Pettay <Olli.Pettay@helsinki.fi>, Jacob Rossi <jrossi@microsoft.com>, "www-dom@w3.org" <www-dom@w3.org>, "schepers@w3.org" <schepers@w3.org>, "jeresig@gmail.com" <jeresig@gmail.com>, Jonas Sicking <jonas@sicking.cc>
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