[whatwg] HTML5 History Management

[Nathan Hammond]

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  
= ?).