> 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.
This is the question I'm most interested in. You say the use cases are limited. How do you know? Are you speaking about when you would use mutation events, or do you have data on when authors use them on the web? Is one of the limited use cases on a high traffic web site? Does Mozilla share your opinion? Do others? I have the same questions about Ojan's claim. > 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.). This is an interesting data point. If we just need an event for an extension to reapply its magic to new content, a global, asynchronous DOMContentChanged event might work. If we introduced an API like that, and gave extensions developers time to update, we could probably remove mutation events without harming extensions. I'd like to give the same kind of consideration to data about web content. > 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.). I'm not sure this plan makes sense. If we plan to do #2 (remove mutation events), #1 (make mutation events asynchronous) may not be worth the effort. Also, I'm not sure that the best time to remove mutation events depends on what we do (communication) -- it most likely depends on what others do (changing web content not to use mutation events, or not). On the other hand, I would be willing to chip in to see "Friends Don't Let Friends Use DOM Mutation Events" in big letters over highway 101 :). Geoff _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
