W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: Mutation events replacement

From: Dave Raggett <dsr@w3.org>
Date: Wed, 06 Jul 2011 09:27:48 +0100
Message-ID: <4E141C84.3090701@w3.org>
To: Olli@pettay.fi
CC: Olli Pettay <Olli.Pettay@helsinki.fi>, Ojan Vafai <ojan@chromium.org>, Boris Zbarsky <bzbarsky@mit.edu>, public-webapps@w3.org
On 04/07/11 21:43, Olli Pettay wrote:
> On 07/04/2011 09:01 PM, Dave Raggett wrote:
>> On 04/07/11 17:57, Olli Pettay wrote:
>>> Mutation listener could easily
>>> implement old/new value handling itself, especially if it knows which
>>> attributes it is interested in.
>>
>> How exactly would the listener know the previous state?
>
>
> In the easiest case when the script cares about only one specific 
> attribute:
> element.addAttributeChangeListener(
>   {
>     prevVal: element.getAttribute("foo"),
>     handleMutation: function(node, changeTarget) {
>       if (node == changeTarget) {
>         // do something with this.prevVal
>         ...
>         this.prevVal = element.getAttribute("foo");
>       }
>     }
>   });

How does that scale to the case where you set the observer on the 
document or on a div element acting as a contained for content editable 
content?  If I am not mistaken you would have to keep a copy of the 
document, or of that div element respectively, and keep it in sync with 
all of the mutations, which sounds like a major performance hit, and 
something you don't need to incur with the current DOM mutation events.

-- 

  Dave Raggett<dsr@w3.org>  http://www.w3.org/People/Raggett
Received on Wednesday, 6 July 2011 08:28:30 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:46 GMT