Re: Replacement for mutation events

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?


-Olli


   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