Re: Mutation events replacement

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