- From: Andrew Oakley <andrew@ado.is-a-geek.net>
- Date: Wed, 02 Feb 2011 13:30:42 +0000
- To: Olli@pettay.fi
- CC: Olli Pettay <Olli.Pettay@helsinki.fi>, Jacob Rossi <jrossi@microsoft.com>, "www-dom@w3.org" <www-dom@w3.org>, "schepers@w3.org" <schepers@w3.org>, "jeresig@gmail.com" <jeresig@gmail.com>, Jonas Sicking <jonas@sicking.cc>
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. 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.
--
Andrew Oakley
Received on Wednesday, 2 February 2011 13:49:25 UTC