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

Re: Mutation events replacement

From: Ryosuke Niwa <rniwa@webkit.org>
Date: Thu, 7 Jul 2011 13:58:45 -0700
Message-ID: <CABNRm60-dfgh8Nj=yM0XyRejN4LXOrYo99vRkTbhsX-x3r5Jww@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Olli@pettay.fi, Rafael Weinstein <rafaelw@google.com>, Aryeh Gregor <Simetrical+w3c@gmail.com>, Adam Klein <adamk@google.com>, Anne van Kesteren <annevk@opera.com>, Webapps WG <public-webapps@w3.org>
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.

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

- Ryosuke
Received on Thursday, 7 July 2011 20:59:32 UTC

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