- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Mon, 04 Jul 2011 23:43:23 +0300
- 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 UTC