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

[Geoffrey Garen]

Hi Ojan.

> Mutation events are a huge source of crashes and they complicate WebCore code considerably.

Indeed. I also think mutation events unnecessarily complicate the API space from a web content author's perspective.

> 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. 

I think this is the key question -- how does existing content use mutation events, and what would we risk by changing or eliminating them?

Another important question is whether/how important DOM API compatibility tests, like the Acid tests, use mutation events.

What's the best way to answer these questions? I think that answer will probably guide our perspective on the options you listed.

> Here's some options I see:
> 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.
This seems like the most appealing option if (a) backwards compatibility requires us to keep mutation events, but (b) making them asynchronous doesn't harm that backwards compatibility in significant ways.
> Drop support for them with no replacement.
This seems like the most appealing option if mutation events just aren't used.
> Complete the implementation of beforeinput/input events to support editing use-cases then do 1 or 2.
This seems like the most appealing option if we're going to try to coordinate our action on mutation events with third party changes. (Otherwise, the beforeinput/input events can be an independent concern.)
> 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).
I just skimmed this API description, but my take on it is that it's very similar to #1 -- it's still a pretty intrusive set of mutation-related APIs, just an asynchronous one. I'm not convinced by Jonas Sicking's claim that this API is significantly different because it lacks a bubble / capture phase. I don't think that was ever the main problem with mutation events.

So, I prefer #1 to #4, since #4 just seems like a more complicated way to avoid the burden of synchronous mutation events.

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