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. 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? 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 ?
'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. -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
