- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 7 Jul 2011 16:05:38 -0700
- To: John J Barton <johnjbarton@johnjbarton.com>
- Cc: Rafael Weinstein <rafaelw@google.com>, Ryosuke Niwa <rniwa@webkit.org>, 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 <johnjbarton@johnjbarton.com> wrote: >>>> 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. > > 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. This is more comprehensive than anything else so far ;-) Unfortunately being able to mutate the DOM itself isn't enough. We also need to prevent a whole host of other things, such as performing synchronous XHR, navigating a document, calling alert() or showModalDialog(), likely setting document.domain, setting scroll positions etc. The list will be long and implementation dependent. This is because all these things can indirectly mutate the DOM. So more comprehensive is still needed. And unfortunately you'd likely need to do research into each browser implementation and see what invariants they depend on and which APIs can change those invariants. This is extra hard given that there are at least two non-open-source implementations out there. / Jonas
Received on Thursday, 7 July 2011 23:06:35 UTC