W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: Mutation events replacement

From: John J Barton <johnjbarton@johnjbarton.com>
Date: Thu, 07 Jul 2011 16:49:41 -0700
Message-ID: <4E164615.8030105@johnjbarton.com>
To: Olli@pettay.fi
CC: Rafael Weinstein <rafaelw@google.com>, Ryosuke Niwa <rniwa@webkit.org>, Jonas Sicking <jonas@sicking.cc>, Aryeh Gregor <Simetrical+w3c@gmail.com>, Adam Klein <adamk@google.com>, Anne van Kesteren <annevk@opera.com>, Webapps WG <public-webapps@w3.org>
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.

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:22 UTC