- From: Rafael Weinstein <rafaelw@google.com>
- Date: Wed, 12 Oct 2011 10:50:50 -0700
- 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