- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Wed, 02 Feb 2011 14:44:02 +0200
- 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 01:50 PM, Andrew Oakley wrote:
> On 02/02/11 11:01, Olli Pettay wrote:
>> Hi all,
>>
>> I'm hoping we could prototype Jonas' proposal in Gecko
>> pretty soon (using moz prefix of course!). It should be very easy to
>> implement. The method names in the proposal could need still some tweaking.
>> Maybe there could be just two methods
>> addMutationObserver(SOME_CONSTANT, callback_function)
>> removeMutationObserver(SOME_CONSTANT, callback_function)
>
> Looking at the current list it looks like we should have an argument for
> "just this node" or "any node in this tree". That would get rid of 4
> out of the 10 methods and seems more clear to me.
>
> 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?
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?
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 :)
-Olli
This
> is only important when the code that performed the mutation is relying
> on the actions of the notification. If the author of the code is
> relying on the notifications to do something they must know that
> something needs to be done, and can therefore make the relevant calls
> directly in ECMAScript.
>
> It feels neater to me to have the notifications always be async. If the
> notifications are occasionally async this might be confusing for
> authors, and is more awkward to implement.
>
>> I'm worried about the performance of selector based
>> proposals. You would need to run selector (after timeout)
>> whenever something in DOM tree changes, but also whenever some
>> state changes (hover, focus, etc). That would mean *lots* of
>> calls to querySelectorAll.
>> Also, the selector based proposals need a separate method for
>> changes in characterdata, like watchCharacterData.
>> That just feels a bit hacky to me.
>
> Agreed.
>
Received on Wednesday, 2 February 2011 12:44:45 UTC