Re: Mutation events replacement

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.
That mutation wouldn't be allowed. What should be done to that
data which the parser can't add to the document?



>
> 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:05:21 UTC