On Thu, Aug 5, 2010 at 2:22 AM, Adam Barth <aba...@webkit.org> wrote:
> On Thu, Aug 5, 2010 at 1:59 AM, Maciej Stachowiak <m...@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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
