Ric Hardacre wrote:
sounds good, and logical when compared with anchor and button onclick
for example.
to clarify, where would the event be attached by default? document or
window? i.e. would i
I'd say it would be attached to the same places as the load event.
I've had a look at the "Session history and navigation" state spec and
if I'm interpreting it correctly, it only solves part of the problem.
Using state objects you would:
1) Implement the popstate event
2) use the window.pushState(stateobject) to push the state into the
"state stack?"
3) When user navigates back, popstate event fires with the state object
From the terminology, I gather that once you popped the state, you
don't have the state in your history anymore? That means after you
navigate back, you can't go forwards again. The state spec also leaves
room for a URI to be associated with the state. But it begs the question
of how will the URI be correlated to the state DOMObject in way that the
URI can restore the state, even if the URI is posted to a web page, or
sent via email to a friend.
However, The good thing about the state spec is that it was created with
the explicit intention of solving the AJAX problem, where as the
onanchor spec is more of a piggy back on to an existing feature. Indeed,
I came up with this spec when I set out to solve the AJAX problem with
the current range of browsers, but fell short, because I couldn't find
an event that would be reliably triggered when the anchor URL changes.
I think the two specs, onanchor/state can be reconciled. The traditional
anchor jumping could be made a behaviour of a modified state spec. Each
jump will be regarded as a new state of page in the session history. It
will however need some modifications for it to be able to perform like
it is on current browsers (going forward, URL change, scrolling).
cheers,
-l
