I am very, very tempted to just get rid of them. As Ojan indicated, the use cases for DOM Mutation events are extremely limited and to me, most of them feel like we should be solving them differently anyway. However, with the introduction of extensions into Chromium and Safari, DOM Mutation events experience a sort of renaissance, being used to sense the DOM changes to re-apply modifications (rewrite URLs, text, etc.). So I think we will upset a bunch of extensions developers if we just go cold turkey, which is probably not the right thing -- regardless of whether techniques they employ are sound or not. With this in mind, I think we should do #1 and #3, then #2 after some time and loud over-communication (like Inspector warnings, blog posts, billboards on Hwy 101 etc.). :DG< On Mon, Aug 9, 2010 at 5:11 PM, Geoffrey Garen <ggaren@apple.com> wrote:
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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev