Tab Atkins Jr. schrieb:
On Sat, Oct 17, 2009 at 12:22 AM, Jonas Sicking <jo...@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 <gmaxw...@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?
