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 <shogu...@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<shogu...@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.

Reply via email to