[whatwg] HTML5 History Management
Nathan Hammond
nathan at nathanhammond.com
Wed Jul 29 19:38:36 PDT 2009
Ian et al.:
About a year ago, after I wrote the first version of my history
manager, I began the process of looking into the HTML5 history spec
and had a few conversations with folks like Bertrand Le Roy, Brad
Neuberg, and Brian Dillard. Some of my notes from back then have been
addressed, but I've still got a few more. Everything is included below
for your reading pleasure. Enjoy!
Nathan
***
Clarifications
1. window.history.pushState({}, "Title", "/path/to/new/file.html?
s=newvalue#newhash") replaces the current document object with the one
specified by the new URL. It then causes the event popstate to fire
immediately after the load event, correct?
2. window.history.pushState({}, "Title", "#newhash") creates a new
history state object with the specified data object, the specified
title, the same document object, and a location object that replaces
the existing hash with "#newhash", correct?
Possible Action Items
1. Specify the order in which history related events are triggered.
In what order would one expect the events triggered by
window.history.pushState({}, "Title", "#newhash")? There are two
events of interest: popstate, and hashchange. If popstate is fired
first it will make it easy to catch programmatic versus user changes
to the hash and respond accordingly. This would imply queueing the
popstate event prior to changing the URL when the document isn't
changing, or having the browser respond to the popstate event by
changing the hash. (This concern exists only when the new URL reuses
the same document object.) Regardless of the outcome, the order in
which these events are triggered really needs to be specified and each
individual triggering of these pair of events needs to be assured to
occur entirely before the next time the pair are triggered.
2. Specify a method to allow access to the history stack. (At least
readable within the context of same-origin, possibly mutable.)
This would allow for understanding on the client side of a user's path
through the site, even after navigating away from the page. If this is
not implemented the absolute first thing I will be implementing is a
method to track this information, a rather large duplication of effort
for something that could easily be made available. This would involve
a something like currentstate = { _previous: currentstate, title:
window.title, newval: true }; plus a form-based storage mechanism to
repopulate state in case the user exits on a page which they manually
changed the hash to get to (which would not have access to the data
object upon revisiting later since there wouldn't be one stored with
that history state).
I'm aware of the privacy ramifications, but at the same time, I'm
going to be exposing those exact same concerns with the above method.
3. Specify a method to modify the current history state without adding
a new history point.
This would alleviate the need for the (incredibly brittle) form-based
storage mechanism I describe above.
4. Specify additional properties on the hashchange event.
Lots of possible useful information with the number one most important
being the new hash that triggered the event to prevent race conditions
reading window.location.hash. Other fun things that are a bit more pie
in the sky: the previous hash and knowledge of how it was triggered
(manually? pushState? window.location.hash = ? window.location.href
= ?).
More information about the whatwg
mailing list