W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2009

[whatwg] <a onlyreplace>

From: Nelson Menezes <flying.mushroom@gmail.com>
Date: Sun, 18 Oct 2009 21:31:57 +0200
Message-ID: <a440ea080910181231rd944dcdj1b50fcd68afced54@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:18 UTC