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

Re: Mutation events replacement

From: Ryosuke Niwa <rniwa@webkit.org>
Date: Thu, 7 Jul 2011 15:53:50 -0700
Message-ID: <CABNRm62CSc7b6xmY=G3DwVGOPk73d2OJNYRa-EaJwrzc7ED9RA@mail.gmail.com>
To: John J Barton <johnjbarton@johnjbarton.com>
Cc: Rafael Weinstein <rafaelw@google.com>, Jonas Sicking <jonas@sicking.cc>, Olli@pettay.fi, Aryeh Gregor <Simetrical+w3c@gmail.com>, Adam Klein <adamk@google.com>, Anne van Kesteren <annevk@opera.com>, Webapps WG <public-webapps@w3.org>
On Thu, Jul 7, 2011 at 3:43 PM, John J Barton
>  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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:22 UTC