On Aug 9, 2010, at 8:21 PM, Timothy Hatcher wrote: > On Aug 9, 2010, at 7:52 PM, Dimitri Glazkov wrote: > >> 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.). > > > Adding input/beforeinput events (#3) wont solve the need of most extension > developers that use mutation events today (the examples you cite). So that > makes it hard to remove them, especially over time, no matter how much > warning you give.
Would it satisfy extension use cases if DOM mutation events got batched and dispatched asynchronously as the generic DOMSubtreeModified?[1] Do extensions need detailed change notification, or is a general "something changed" notification good enough? I think reducing mutation event support down to just DOMSubtreeModified, and firing it only at the very end of operations that should be atomic, would greatly reduce the risk of mutation-event-induced crashing, but would probably still serve the key use cases. For performance reasons, it would be even better to have a type of notification that doesn't have to allocate an event object, as that is a large part of the performance hit from mutation events. I gather that is what the fancier new mutation events proposal does. Regards, Maciej [1] http://www.w3.org/TR/DOM-Level-3-Events/#event-type-DOMSubtreeModified _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
