Re: Mutation events replacement

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.
>>
>> 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.
>
> Totally agreed.
>>
>> I really like Rafael's proposal to pass a list of mutations that has
>> happened to the notification callbacks. This has the advantage that
>> scripts get *all* the changes that has happened at once, making it
>> possible to make decisions based on all changes made, rather than
>> piece-wise getting the information in separate callbacks. It also has
>> the advantage that we can provide much more detailed information
>> without having to make multiple calls from C++ to JS which is good for
>> performance. For example it seems very doable to provide lists of all
>> nodes that has been removed and added while still keeping performance
>> reasonable.
>
> Enthusiastically agreed.
>>
>> I'll write up a proposal based on this idea. Others should feel free
>> to beat me to it :)
>
> Nice!  Looking forward to it.
>>
>> The main concern that I have with this proposal is that it's so
>> different from mutation events that it might not satisfy the same use
>> cases. Consider a widget implementation that currently observes the
>> DOM using mutation events and makes it possible to write code like:
>>
>> myWidgetBackedElement.appendChild(someNode);
>> myWidgetBackedElement.someFunction();
>>
>> where someFunction depends on state which is updated by the mutation
>> event handler. Such a widget implementation is simply not doable with
>> these semi-asynchronous callbacks.
>
> Right.  But on the other hand, if this code were to run inside a mutation
> observer, it won't work in your proposal either.  So the questions is
> whether writing a function that depends on state updated by the mutation
> observer without a mutation observer, and then later calling it inside a
> mutation observer happens frequently enough to annoy developers or not.
>>
>> On the other hand, maybe this isn't a big deal. We are definitely
>> short on use cases for mutation events in general which is a problem.

Right. Olli & Jonas, I'd really like to understand your thinking about this.

Are we not understanding something about your proposal?

If accommodating the above is a goal, it seems like the only option is
to have mutation events be fully synchronous. I.e. It doesn't seem
acceptable to encourage a widget author to expose an API that depends
on never being called inside a mutation callback and/or prevents it
from being used as a building block for a higher-level abstraction.

>
> Agreed.  We probably need more real-world use cases.
> - Ryosuke
>

Received on Thursday, 7 July 2011 21:32:53 UTC