Re: Mutation Observers: a replacement for DOM Mutation Events

On 12/10/11 3:26 AM, Tab Atkins Jr. wrote:
> On Mon, Oct 10, 2011 at 7:51 PM, Sean Hogan<shogun70@westnet.com.au>  wrote:
>> On 24/09/11 7:16 AM, Adam Klein wrote:
>>> - Is free of the faults of the existing Mutation Events mechanism
>>> (enumerated in detail here:
>>> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0779.html)
>> A simpler solution that is free from the faults listed in that email would
>> be to have (at max) one mutation observer for the whole page context. I
>> guess this would be called at the end of the task or immediately before page
>> reflows.
>>
>> If a js lib (or multiple libs) want to provide finer grained mutation
>> handling then let them work out the details.
> That seems unworkably restrictive.  It's very easy to imagine multiple
> libraries listening for different kinds of things at the same time.
> Libraries would just end up re-implementing event distribution, which
> is something we can avoid by doing it correctly now.

This proposal doesn't entirely avoid the issue of event distribution. 
There is no equivalent of event.stopPropagation() and hence no way to 
prevent mutation records being delivered to observers. The observers may 
have to be written with this is in mind.

For example, what if two observers can potentially handle the same 
mutation - which one should handle it?

Alternatively, some code might respond to an attribute by adding content 
to the DOM. What if there are mutation listeners that could respond to 
that added content? Is it desired that they ignore or handle it?

Another pattern that doesn't seem to be reliably handled is mutations 
within DOM fragments that are temporarily removed from the document. 
That is:
- if the fragment always remains in the document then all mutations can 
be monitored by observers on the document (or document.body), but
- if the fragment is removed from the document followed by mutation 
observers being called, then  any further mutations won't be delivered 
to the observers, even when the fragment is reinserted into the document.

The exact behavior in this scenario depends on whether mutations 
complete within one microtask or more than one

Sean.

Received on Wednesday, 12 October 2011 11:01:35 UTC