Re: Mutation events replacement

On Thu, Jul 7, 2011 at 3:43 PM, John J Barton
>  On Thu, Jul 7, 2011 at 1:58 PM, Ryosuke Niwa <> wrote:
>>> On Thu, Jul 7, 2011 at 12:18 PM, Jonas Sicking <> 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