Andrew, I wanted to correct this because I feel the history is slightly different and I didn't like it at that time. Sizzle has never used DOMSubtreeModified event that I am aware of.
For some time John Resig used something like the DOM Mutation Events and technique I was already using in NWMatcher, the difference is that his implementation was slowing down all and every DOM operation while the handlers were in place so he was forced to remove it when people let him know about the problem. He also went so far as to accuse Peppy author (James Donaghue) claiming that his code was stolen from Sizzle forcing him to put credits in his code pointing to John work. I didn't like that either ;-) http://ajaxian.com/archives/peppy-css3-selector-engine Diego On 18 Gen, 09:38, Andrew Dupont <goo...@andrewdupont.net> wrote: > 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 prototype-core@googlegroups.com > > To unsubscribe from this group, send email to > > prototype-core-unsubscr...@googlegroups.com > > For more options, visit this group > > athttp://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 prototype-core@googlegroups.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
