Re: Mutation events replacement

On 07/04/2011 09:14 PM, John J. Barton wrote:
> 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?
DOM mutations will not act differently, but mutation listeners
will be called later.

> Code tested outside of mutation listeners can fail
> inside of mutation listeners, correct?
If the code relies on mutation listeners, then yes.


>
> 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.
There are no real async operations, there is just the queue of mutation 
notifications. But sure, it can look like async.
But you propose that all the mutation notifications are done
asynchronously? One could easily add a small JS layer over the proposed
API to get fully async behavior.


> Developers will
> hate it, just like they hate XHR asynchrony,
(They do? Hmm, and I'll propose to deprecate sync XHR, since it is
bad for UX. But this topic has nothing to do with mutation events.)



-Olli

> 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
>

Received on Tuesday, 5 July 2011 09:10:21 UTC