Re: Mutation events replacement

On 7/4/2011 9:38 AM, Olli Pettay wrote:
> On 07/04/2011 07:23 PM, John J. Barton wrote:
>> On 7/3/2011 1:23 PM, Boris Zbarsky wrote:
>>> On 7/3/11 2:43 PM, John J. Barton wrote:
>>>
>>> I'm not sure what you're asking... The whole point of the proposed
>>> model is that if someone tries to do a mutation the mutation _will_
>>> happen and will complete. _Then_ listeners, if any, will be notified.
>>> What are you worried about working or failing?
>>
>> According to Olli, some functions in mutation listeners will fail.
> What? I don't understand this at all.
Sorry, it was actually in Jonas' post you quoted:

>The only undesirable feature is that code that mutates the DOM from
>inside a callback, say by calling setAttribute, can't rely on that by
>the time that setAttribute returns, all callbacks have been notified.
>This is unfortunately required if we want the second desirable
>property listed above.


If I understand correctly, this description understates the problem.   
Isn't it the case that all DOM mutations will act differently in 
mutation listeners?  Code tested outside of mutation listeners can fail 
inside of mutation listeners, correct?

This is indeed an undesirable feature and I don't believe it is 
necessary.  We can achieve the second desirable property, which is 
really about avoiding mutation in mutation listeners, in other ways. 
Instead of special case asynchrony, make it explicit asynchrony.  
Developers will hate it, just like they hate XHR asynchrony, but it's 
better than unreliable programs.
>
>  The
>> list of functions is not specified directly, but is implicit in the
>> algorithm: some function's actions become asynchronous.
> No. Change notifications are queued, and the listeners handling the
> queue will called at the time when the outermost DOM mutation is about
> to return.
How can I reconcile your answer with the idea that setAttribute() does 
not work synchronously in my mutation listener? Can my mutation listener 
mutate the DOM and expect those mutations to act the way they do outside 
of the listeners?  My understanding is no: the API works differently 
inside of mutation listeners.

jjb