- From: Nelson Menezes <flying.mushroom@gmail.com>
- Date: Sun, 18 Oct 2009 21:31:57 +0200
2009/10/18 Tab Atkins Jr. <jackalmage at gmail.com>: > On Sun, Oct 18, 2009 at 12:20 PM, Nelson Menezes > <flying.mushroom at gmail.com> wrote: >> 2009/10/18 Tab Atkins Jr. <jackalmage at gmail.com>: >>> As long as the event bubbles, you can always just listen at the >>> document root and then check event.target to see who got updated. >>> That way you don't have to wait, nor do you have to know which >>> specific bits are getting replaced. >> >> You would want the event to fire once, though, regardless of how many >> targets are being replaced. Otherwise you won't be able to distinguish >> 3 events generated by one response with content for #div1,#div2, and >> #div3. Event.target should be the original <a> or <form> element, or >> the window object if the request originated via scripting. > > My thoughts were that the event fires at the replaced elements, not > the <a> or <form> that triggered the navigation. ?So you *would* be > able to distinguish multiple elements, as their event.target would > point to each element as appropriate. > > This isn't a click or whatever event, it's a load/unload event. ?The > <a> or <form> isn't doing either. Sorry, I had in mind being able to re-apply event listeners to the DOM once the new content was loaded. Of course you can do that in several localised places rather than overall on the whole document (it will be more efficient anyway). Still, it would be nice to be able to identify that "all my bits of content are now loaded" and being able to have an event handler that gets called once, rather than having to account for all the IDs loading independently: I might want to do something that involves several parts of the new content (e.g. highlight it to make the change obvious to the user). Nelson Menezes http://fittopage.org
Received on Sunday, 18 October 2009 12:31:57 UTC