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

Re: Mutation events replacement

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Mon, 04 Jul 2011 23:43:23 +0300
Message-ID: <4E1225EB.7050508@helsinki.fi>
To: Dave Raggett <dsr@w3.org>
CC: Ojan Vafai <ojan@chromium.org>, Boris Zbarsky <bzbarsky@mit.edu>, public-webapps@w3.org
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");
       }
     }
   });



>
> For a concurrent editing app, it is important to be able to describe
> changes reversibly so that you can revert the DOM when a given local
> edit isn't accepted, or you need to revert before applying accepted
> changes from other clients. I have been able to get this to work fine
> with the existing mutation events. Of course, I avoid changing the DOM
> within a mutation event listener, but it is easy to defer such changes
> by a call to setTimeout, e.g. with a time of zero. I would be quite
> happy for the browser to throw an exception when a mutation event
> listener tries to call an unsafe API, as this way developers would
> rapidly learn of their mistake and switch to better practices.
>
Received on Monday, 4 July 2011 20:43:52 GMT

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