On Thu, Jul 7, 2011 at 3:43 PM, John J Barton <johnjbarton@johnjbarton.com>wrote: > > On Thu, Jul 7, 2011 at 1:58 PM, Ryosuke Niwa <rniwa@webkit.org> wrote: >> >> >>> On Thu, Jul 7, 2011 at 12:18 PM, Jonas Sicking <jonas@sicking.cc> wrote: >>> >>> >>>> I don't think John J Barton's proposal to fire "before mutation >>>> notifications" is doable. >>>> >>>> >>> I concur. Being synchronous was one of the reasons why the existing DOM >>> mutation events don't work. We shouldn't adding yet-another synchronous >>> event here. >>> >>> >> However, my proposal need not be synchronous in the sense that is > important here: 'before' mutation listeners need not able to mutate, only > cancel. So it's not yet another synchronous event. Developers would use > their handler to build a new mutation event and fire it on the next turn: > it' s essentially asynchronous. Being able to cancel is dangerous enough for me. There are lots of reasons why 'before' events may not be practical, > including lack of enthusiasm on the part of the implementors. You folks are > the experts, I'm just trying to contribute another point of view. Thus I > want to point out that for the critical issue of preventing mutation > listeners from mutating, all you have to do to Jonas' algorithm is prepend: > > 0. If notifyingCallbacks is set to true, throw > MutationNotAllowedInBeforeMuta**tionCallbacks. Implementing this feature is excessively hard and time-consuming for many implementors as far as I know. - Ryosuke
Received on Thursday, 7 July 2011 22:54:45 UTC