[webkit-dev] DOM Mutation Events. WAS: Fwd: webkit editing rewrite?

[Ojan Vafai]

On Thu, Aug 5, 2010 at 2:22 AM, Adam Barth <abarth at webkit.org> wrote:

> On Thu, Aug 5, 2010 at 1:59 AM, Maciej Stachowiak <mjs at apple.com> wrote:
> > If mutation events tend to break editing, one simple solution is to turn
> then off within the scope of editing operations and send a single mutation
> event at the end. It's not clear if that kind of solution would be
> appropriate to expose to Web content, though; you can't do the RAII idiom in
> JavaScript so there could be too much risk of staying stuck in the "mutation
> events deferred" state. On the other hand, a dynamic-wind-style solution
> might be appropriate. This is one tiny example of how the same abstractions
> might not be right internally and externally.
>
> If we don't already have it, we definitely want a RAII for turning off
> mutation events (or at least ASSERTing that we're not trying to fire
> them) for the parser.  The new and old tree builders might explode if
> they ever fire a mutation event.


I'm trying to figure out what we should do with DOM Mutation Events. The
general agreement from the www-dom discussion of mutation events was that
they are the wrong abstraction for editing related code. beforeinput/input
events meet editing needs better. So, that leaves a small list of relatively
low-priority use-cases. See
http://www.w3.org/2008/webapps/wiki/MutationReplacement for some of them.

Mutation events are a huge source of crashes and they complicate WebCore
code considerably. Also, I don't see any evidence that mutation events are
used much other than as a blunt dirty bit for editing code, which can now be
replaced with the input event. Here's some options I see:

   1. Make the existing mutation events them async. That would address all
   the issues with them except for the performance cost and would only be
   backwards-incompatible for the small percentage of sites that depend on the
   events firing synchronously.
   2. Drop support for them with no replacement.
   3. Complete the implementation of beforeinput/input events to support
   editing use-cases then do 1 or 2.
   4. Same as above, but also implement a low-level replacement for mutation
   events (e.g. something like
   http://lists.w3.org/Archives/Public/www-dom/2009AprJun/0081.html).

Do any of these options sound feasible or is the only option to do the very
large amount of work to make existing mutation events work?

Ojan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100809/0d5070b9/attachment.html>