Re: Mutation events replacement

On Mon, Jul 4, 2011 at 8:40 PM, John J. Barton
<johnjbarton@johnjbarton.com>wrote:

> On 7/4/2011 6:39 PM, Boris Zbarsky wrote:
>
>> On 7/4/11 12:23 PM, John J. Barton wrote:
>>
>>  By restricting mutation listeners to explicitly avoid DOM mutation, the
>>> most sophisticated case is no different than the simple case. Then all
>>> three can be accommodated.
>>>
>>
>> If such a restriction were feasible, it might be worth looking into.  It
>> would involve not passing any DOM nodes to the mutation listener, I suspect.
>>
>
We'll also need to make window and other objects inaccessible from the
mutation listener.  Even then, the script may have a global reference to
some DOM node.  Frankly, I don't think such a restriction is feasible to
implement, and I don't want to discuss about pre-mutation events or observer
callbacks any more at this point.

Instead, let us focus on Jonas' proposal about replacing existing mutation
events by post-mutation observer callbacks.  So far, I've seen the following
complaints and suggestions about Jonas' proposals:

   - *Information is not complete* - Some apps want to know exactly what
   happened so that they can sync data, create an inverse operator, etc...
   - *Pseudo-sync/async is confusing* - In Joans' proposal, outer most
   mutation calls observers synchronously after the mutation took place whereas
   inner ones call observers asynchronously. This behavior might be confusing
   because the code that expects mutation observers be called synchronously
   works fine outside of observers but doesn't work inside observers.
   - *Call observer once with a list of mutations instead of calling
   observers for each mutation?*

Anything to add?  Does anyone have a revised proposal that addresses the
above points?

- Ryosuke