Rafael Weinstein wrote:
On Thu, Jul 7, 2011 at 1:58 PM, Ryosuke Niwa <rn...@webkit.org> wrote:
On Thu, Jul 7, 2011 at 12:18 PM, Jonas Sicking <jo...@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.
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
