Re: Mutation events replacement

On 03/07/11 04:52, Boris Zbarsky wrote:
> On 7/2/11 2:27 PM, Dave Raggett wrote:
>> n.b. the current mutation events work nicely for the document editing
>> use cases.
>
> Only if you have full control over the set of all registered 
> listeners.  If you do not, you're SOL, because current mutation events 
> can be delivered out of order if mutations happen inside mutation 
> event listeners, for example.
>
> -Boris

Absolutely, for the editing case, such misbehavior would indeed cause 
problems.

However, that does raise a related question.  In the proposed approach 
of asynchronous notification of already applied mutations, how can the 
observer prevent notifications for any changes to the DOM made by that 
observer?  Is it sufficient to for the observer to unregister itself, 
make the changes to the DOM and re-register itself before returning?  A 
use case might be cleaning up the DOM after content editable actions, 
where a developer wants to ensure the DOM is consistent across browsers.

-- 
  Dave Raggett<dsr@w3.org>  http://www.w3.org/People/Raggett

Received on Monday, 4 July 2011 08:44:44 UTC