Re: Replacement for mutation events

On 02/02/2011 03:30 PM, Andrew Oakley wrote:
> On 02/02/11 13:33, Olli Pettay wrote:
>> On 02/02/2011 03:11 PM, Andrew Oakley wrote:
>>> On 02/02/11 12:44, Olli Pettay wrote:
>>>> On 02/02/2011 01:50 PM, Andrew Oakley wrote:
>>>>> Why does this proposal try to make the notifications synchronous?
>>>>
>>>> How would asynchronous notifications work? Should the batch changes
>>>> somehow? If yes, then how exactly?
>>>
>>> I was thinking they could be queued as an HTML5 task, in the same way as
>>> when HTML5 says "queue a task to fire an event ..." for asynchronous
>>> events.
>>>
>>>> Say, a script does
>>>> element.setAttribute("foo1", "foo");
>>>> element.setAttribute("foo1", "bar");
>>>> element.setAttribute("foo2", "foo");
>>>> element.setAttribute("foo2", "bar");
>>>> Would you expect to get only one notification?
>>>> Or 2, or perhaps 4?
>>>
>>> I had not really considered batching the changes.
>>
>> Well, what good does the asynchronous notifications
>> then bring in?
>
> I didn't like the fact that the notifications were normally synchronous
> but sometimes they might not be.
In which case would they be async?
If a callback modifies DOM, the callbacks which are listening that
"inner" mutation would be called after the currently in the 
queue-for-execution callbacks have been executed.
That is still synchronous in the level of the first DOM mutation.

Or are you thinking about some other case?


  It feels like this could be the source
> of subtle bugs (in scripts, rather than browser implementations),
> especially if toolkits were built on top of other toolkits (like
> script.aculo.us on top of prototype) and both toolkits used the
> notifications and expected them to be synchronous.
>
> The fact that you could batch changes could be considered to be a side
> effect of this change, however I think it is a fairly compelling
> argument in itself.

The problem is to define how to batch and when?

Received on Wednesday, 2 February 2011 16:36:11 UTC