Re: Mutation events replacement

On Thu, Jul 7, 2011 at 2:32 PM, Rafael Weinstein <rafaelw@google.com> 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.
>>>
>>> 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.

It's definitely the case that APIs will behave differently inside the
mutation notification, and that the code example showed above would
not work from inside the notification.

Basically I'm asking people to tread carefully inside mutation
notifications and only do the minimal amount of data gathering.

So yes, my proposal only solves the usecase outside mutation handlers.
However this is arguably better than never solving the use case as in
your proposal. I'm sure people will end up writing buggy code, but
ideally this will be found and fixed fairly easily as the behavior is
consistent. We are at least giving people the tools needed to
implement the synchronous behavior.

/ Jonas

Received on Thursday, 7 July 2011 22:20:31 UTC