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
