W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2011

Re: Replacement for mutation events

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Wed, 02 Feb 2011 15:33:57 +0200
Message-ID: <4D495D45.1060505@helsinki.fi>
To: Andrew Oakley <andrew@ado.is-a-geek.net>
CC: 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/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?


   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.
Received on Wednesday, 2 February 2011 13:34:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:17 UTC