[whatwg] <a onlyreplace>
Markus Ernst
derernst at gmx.ch
Sat Oct 17 09:57:49 PDT 2009
Tab Atkins Jr. schrieb:
> On Sat, Oct 17, 2009 at 12:22 AM, Jonas Sicking <jonas at sicking.cc> wrote:
>> Also, what should happen if the user presses the 'back' button?
>
> If the browser can remember what the page state was previously, just
> swap in the old parts. If not, but it at least remembers what parts
> were replaced, make a fresh request for the previous page and
> substitute in just those bits. If it can't remember anything, just do
> an ordinary navigation with a full page swap.
>
> It should act as exactly like current Back behavior as possible.
> We're not really playing with the semantics of navigation, so that
> shouldn't be difficult.
I agree to that. I click a link on a page with an URI, and after
clicking I get a new page with another URI - so if I hit the back
button, I expect getting back the page I had seen before clicking the
link. (Of course with the browser-specific peculiarities - Firefox e.g.
remembers the scroll position, others may not...) The user experience
when using the back button should not differ whether a browser supports
@onlyreplace or not.
> On Sat, Oct 17, 2009 at 3:53 AM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
>> I'm guessing that the rare case where you need to write into a
>> replaced ID you can simply have a JS hook that fires on the load and
>> fixes up the replaced sections as needed.
>
> The functioning of load events here confuses me a bit, because I've
> never done any hacking in that area and so don't understand the
> mechanics well enough to know what's reasonable. Should the new page
> still fire a load event once its replaceable content has loaded? I'm
> guessing that the old page never fires an unload event? I really
> don't know what should happen in this area.
>
> (After giving it a little thought, though, I think we shouldn't change
> the semantics of load/unload/etc. These are still useful, after all,
> for when the page *is* completely unloaded or loaded, such as on first
> visit or when the user hits Refresh. We'd probably want a new set of
> events that fire at the elements being swapped out, and then at the
> new elements once they've been pushed in.)
I admit I don't fully understand load events either. If I get it
correctly, this is about functions called on load, that access elements
in the replaceable parts of the page. A common use case for this is
setting the focus on the first input element of a form. I don't think
that this can be solved at the UA side, some authoring will be
necessary; some possible workarounds are:
- Put page-specific scripts into a separate <script> element with an id,
and include it in the @onlyreplace list;
- make one script that fits for all pages, by checking if an element
exists before doing actions on it;
- instead of using <body onLoad="foo()">, put the function call into a
<script> element at the bottom of the replaceable element.
Anyway such things would be much easier (with or without @onlyreplace)
if the onLoad event handler would be allowed on every HTML element
rather than on window and body only:
<input type="text" name="Name" onLoad="this.focus()">
But this looks that trivial to me - element.onLoad must have been
suggested long ago and been declined for good reasons, I assume?
More information about the whatwg
mailing list