We had talked about having some built-in custom events loosely inspired by DOM mutation events. For example: rather than having separate events for DOMSubtreeModified and DOMNodeInsertedIntoDocument, we'd just fire an `element:updated` event after a call to Element#update or Element#insert. Many scripts that attach behaviors need to know when content has changed.
(And before you say "just use event delegation," let me give you an example: I just finished working on a page where the contents of a PRE element changed based on the results of an Ajax request. Whenever the code changed, the client-side syntax highlighter needed to re-parse the contents. That's the sort of thing I'm talking about.) We haven't rejected the idea outright, but there are a couple things that have kept these events from inclusion by default. First, as Mislav points out, is performance. Calls to Element#fire are synchronous, and mutation events would obviously need to bubble all the way up to `document`. Also, even in browsers that support mutation events natively, we'd want to avoid listening for those events. When John Resig wrote Sizzle, he had planned to cache the results of selector queries, and listened for DOMSubtreeModified so he'd know when to invalidate the cache. Turns out, though, that Firefox doesn't fire mutation events until you start listening for them — and when you attach a listener, it turns them _all_ on, making every DOM operation much slower. The caching worked, but made result retrieval slower than it would have been otherwise. So we'd likely eschew listening for mutation events altogether and just put explicit Element#fire calls in any Element methods that mutated the DOM. But that brings me to the other problem: we'd be introducing a leaky abstraction, perhaps our leakiest yet. Any script that didn't rely on Prototype's custom methods for DOM manipulation wouldn't fire DOM mutation events. So... that's why custom mutation events have remained on the backlog. If you'd like to see this feature in Prototype one-point-whatever, I've a favor to ask: write a simple add-on script that wraps Element#update et al., then do some heavy before/after benchmarking so we can see what we're up against. Cheers, Andrew On Jan 14, 2010, at 1:20 PM, Mislav Marohnić wrote: > Firing custom mutation events in every Prototype method that manipulates the > DOM could generate significant overhead in performance. Maybe the > implementation should be designed in a way that only events that have > registered observers are fired. If no observes are created, no custom events > are ever fired. > > Question is, will this see much usage? I've only used DOM mutation events in > users scripts; i.e. when I wasn't the author of original scripts on the site, > but I wanted to react when these scripts changed something on the page. > > If I'm the author of the website, I don't need mutation events — I can add > functionality directly among the code that does the updating in the first > place. > -- > You received this message because you are subscribed to the Google Groups > "Prototype: Core" group. > To post to this group, send email to email@example.com > To unsubscribe from this group, send email to > prototype-core-unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/prototype-core?hl=en
-- You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to firstname.lastname@example.org To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en