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

Re: Replacement for mutation events

From: Andrew Oakley <andrew@ado.is-a-geek.net>
Date: Wed, 02 Feb 2011 13:11:28 +0000
Message-ID: <4D495800.4010800@ado.is-a-geek.net>
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.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

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