- From: John J Barton <johnjbarton@johnjbarton.com>
- Date: Thu, 07 Jul 2011 16:49:41 -0700
- To: Olli@pettay.fi
- CC: Rafael Weinstein <rafaelw@google.com>, Ryosuke Niwa <rniwa@webkit.org>, Jonas Sicking <jonas@sicking.cc>, Aryeh Gregor <Simetrical+w3c@gmail.com>, Adam Klein <adamk@google.com>, Anne van Kesteren <annevk@opera.com>, Webapps WG <public-webapps@w3.org>
Olli Pettay wrote: > On 07/08/2011 01:43 AM, John J Barton wrote: >> Rafael Weinstein 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. >>>>> In short before spending more time on this, I'd like to see a >>>>> comprehensive proposal, including a description of the use cases it >>>>> solves and how it solves them. I strongly doubt that this approach is >>>>> practical. >> 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 >> MutationNotAllowedInBeforeMutationCallbacks. > > I don't understand how this could really work. > > Just as an example: > What if the mutation listener spins event loop which ends up > touching parser so that it tries to insert new content to the document. I would like to learn what you mean here. The only way I know how to suspend an event and spin a new one is via the debugger API. Is that the case you are concerned with? > That mutation wouldn't be allowed. What should be done to that > data which the parser can't add to the document? Discard, same as any exception, not a special case. jjb > > > >> >> You don't have to to any thing to create a read-only DOM API because you >> already track all possible DOM modifications. The clean-up from the >> throw is similar to the cancel and not different from any other clean-up >> you have to do if the mutation listener fails. >> This is of course not a comprehensive proposal. I'm perfectly fine if >> you choose not to respond because you want to close off this discussion >> and I thank you for the replies so far. >> >> jjb >> >> >
Received on Thursday, 7 July 2011 23:49:27 UTC