[whatwg] HTML5 History Management

[Mike Wilson]

Ian Hickson wrote:
> 
> On Wed, 5 Aug 2009, Nathan Hammond wrote:
> > I should have stated this one with a goal: the ability 
> > to ensure that the popstate event always fires with a 
> > full understanding of the (app/page) state when 
> > navigating through history. This would be lost when a 
> > user manually changes the hash. With that as my goal, 
> > history.replace does not achieve what I am trying to 
> > accomplish. Neither does pushState without a URL as 
> > that still registers a new history point.
> 
> All the information about the state really should be in 
> the URL, such that the state of the app after the user 
> manually changes the hash, and the state of the app after 
> the user returns to a point in the history where he had 
> manually changed the hash, really should be the same.

This has never been true for server-side web applications
so why should it be this way for client-side apps? My
understanding of the purpose of pushState has been that it 
is there to aid client-side apps in behaving like server-
side apps wrt history traversal. Not to make them more 
different and break user expectations.


> I don't think we should encourage cases where the same
> URL can correspond to multiple states, which this would 
> encourage.

This statement confuses me as the whole point of pushState
seems to be to store unique state in addition to the URL.
If the URL can be used to infer the state anyway, then 
what's the point of storing it in the history entry?

But you may have a different purpose for these state 
objects. I'm expecting to store things like step-for-step 
state from wizard-like flows, or user interface state
similar to (but in addition to) the browser's own handling 
of saving/restoring form field values and scroll position.

Though, when taking a more thorough look at what is 
spec:ed, it seems these use cases are indeed not supported, 
due to state update limitations and how events are ordered.
It would be very interesting to hear about the scenarios
you have in mind, to be able to comment correctly. It
would be great if you could flesh out (or point to) a 
concrete example of correct and intended usage of this 
history state object mechanism.


> > [suggesting .hashvalue on hashchange event]
> 
> I really don't follow.
> 
> Imagine you're updating what's visible based on the hash, 
> and the user changes the hash twice in a row quickly such 
> that by the time you get the first event, the location's 
> already changed again. Why wouldn't you be happy to 
> ignore the first location?

F ex, because your client-side app may update some state 
based on what (or how many times) individual fragments have 
been visited. Maybe something in the spirit of "read count"
or so.


Two other notes about the history state mechanism:

1) The "popstate" event is sort of a misnomer as it doesn't 
"pop" the state. Popping would imply removing it from its 
stack, but this is not the case as it remains in place in 
the history to be retrieved any number of times. A better 
name could be something like "restorestate".

2) This text at the end of 6.10.1:
| When state object entries are added, a URL can be 
| provided. This URL is used to replace the state object 
| entry if the Document is evicted.
I'm not sure how to interpret this. Does it (implicitly) 
say that all state objects are evicted when the owning 
Document is evicted? And does the popstate event really 
supply the URL string in its .state member, instead of the 
real object, in these cases?


One super-minor nit: 

In 6.10.3 we have:
| (which happens during [[session history traversal]], as 
| described above)
The link points to 6.11.9 which is below, not above.


Best regards
Mike Wilson