Re: Mutation events replacement

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.

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 22:43:25 UTC