Re: Mutation events replacement

On Thu, Jun 4, 2009 at 4:15 AM, Joćo Eiras <joaoe@opera.com> wrote:
>> These are *not* DOM-Event listeners. No DOM Events are created, there
>> are no capture phases or bubbling phases. Instead you register a
>> listener on the node you are interested in being notified about, and
>> will get a call after a mutation takes place. The listeners are called
>> as follows:
>>
>
> I find this behavior limiting in some regards and makes mutation events less
> useful.

Less useful to do what? What's your use case?

> You specify some functions which add listeners for sub tree
> modifications though.
> Why not keeping the DOM events model for sub tree modification cases, and
> optimize single node mutation listeners with the API you propose?

I'm not sure I follow what you are suggesting. Which DOM Events are
you suggesting we keep?

> Another possible way would be to extend DOM events to tell that one only
> wants a listener for the AT_TARGET phase.
> Currently, if the 3rd parameter is true then it's capturing phase, else if
> it's false it's at_target and bubbling. Why not extend this argument with
> another possible value, or overloading the function with an enumeration on
> the 3rd parameter ?

This is significantly more complicated to implement. In order to
optimize and not build the parent chain we would have to know that
there are no listeners on the parent chain that aren't AT_TARGET-only.

>> 'AttributeChanged': Called when an attribute on the node is changed.
>> This can be either a attribute addition, removal, or change in value.
>> If setAttribute is called the 'AttributeChanged' listener is always
>> called, even if the attribute is given the same value as it already
>> had. This is because it may be expensive to compare if the old and new
>> value was the same, if the value is internally stored in a parsed
>> form.
>
> The overhead of comparing the previous with the new value inside the engine
> is a fragment of the overhead of calling an ecmascript callback and doing
> the same comparison in ecmascript. Doing so will also prevent the callback
> from being called way too many times. So I think it should only be called
> when the value actually changes.

If we only call the callbacks when the value changes, this means that
we have to check if the value changes on every call to setAttribute.
Even though most likely 99.9% of the time the value will change (why
did the page call setAttribute if not to change the value?).

Like you say, we'd get a decent win in the case when the value doesn't
change. But that is very rare. Compared to a small cost that we have
to take every single time.

/ Jonas

Received on Thursday, 4 June 2009 11:34:01 UTC