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 <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.
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
