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

[Dimitri Glazkov]

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 at 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 at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>