- From: Andrew Oakley <andrew@ado.is-a-geek.net>
- Date: Wed, 02 Feb 2011 13:11:28 +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 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. The current MutationTarget algorithm would result in a separate notification for each update, even in cases like this. Batching changes would almost certainly increase performance. Perhaps we should not allow two identical notifications one after another. Because the AttributeChanged notifications do not indicate which attribute was changed, or the value of the attribute the notifications for all of these updates would be identical and therefore we would get a single notification. If a script did this: element.setAttribute("foo1", "foo"); element.setAttribute("foo1", "bar"); element.appendChild(...); element.setAttribute("foo2", "foo"); element.setAttribute("foo2", "bar"); you would get AttributeChanged, ChildlistChanged, AttributeChanged. If there was no ChildlistChanged listener would only get one AttributeChanged. I'm not sure I like this - if two separate bits of code added different listeners they could receive different notifications from if they were operating on there own. I can't actually think of a reason why this would be a problem in practice though. > It is possible that async notification could be > faster, if we can come up with some reasonable > way to batch/merge notifications together. > The problem is the "reasonable" part :) We probably need to agree on what "reasonable" means in this case and go from there. In any case, if people think that the general idea of using a model like "MutationTarget" but with async notifications is a good idea I could think about this more carefully and attempt to write it up (and perhaps get it on the webapps wiki). If people don't like the general idea (or don't think it could be implemented in major browsers) then I don't think there is much point trying to work out the details. -- Andrew Oakley
Received on Wednesday, 2 February 2011 13:30:08 UTC