W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: Mutation Observers: a replacement for DOM Mutation Events

From: Rafael Weinstein <rafaelw@google.com>
Date: Wed, 12 Oct 2011 10:50:50 -0700
Message-ID: <CABMdHiR9-hh7i1xBP0qsAY6-gckh86kN+x5sdCyGpAaiY89vhg@mail.gmail.com>
To: Sean Hogan <shogun70@westnet.com.au>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Adam Klein <adamk@chromium.org>, public-webapps@w3.org, Olli@pettay.fi, Ojan Vafai <ojan@chromium.org>, rniwa@chromium.org, Jonas Sicking <jonas@sicking.cc>, annevk@opera.com, arv@chromium.org
Hi Sean,

I find it hard to reason about cases in the abstract. None of the
examples you list seem concerning to me (i.e. I believe they can be
properly handled), but perhaps it's a failure of my imagination.

Maybe you can provide concrete examples (i.e. with code snippets,
actual instances of use cases, etc...)

On Wed, Oct 12, 2011 at 4:00 AM, Sean Hogan <shogun70@westnet.com.au> wrote:
> 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 17:51:18 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:36 UTC