[whatwg] HTML5 History Management

[Ian Hickson]

On Sun, 16 Aug 2009, Mike Wilson wrote:
> 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?

It's always supposed to be true for server-side Web apps too, no?


> 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.

Your understanding is correct.


> > 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?

It's mostly about being able to track extra state that isn't important to 
the user. For example, if you have an application with many boxes, and two 
states, one with one box open, and another with another box open, and the 
boxes are randomly dotted around but move when a box is opened or closed, 
and you then hit back-forward-back-forward, you would want the same two 
boxes to move in the same way each time. However, if you just jump 
straight to the URI representing those two states, the exact position of 
the boxes doesn't matter, and might differ each time. The state object is 
for keeping track of that kind of thing (the position of the boxes).


> 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.

I've tried to fix this by making popstate more synchronous.


> > > [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.

Fair enough. I've made hashchange synchronous also.


> 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".

That's possible. onrestorestate="" is not as clear as onpopstate="", 
though, so I've not chnged it.


> 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?

That text is meaningless. I've removed it.


> 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.

Thanks, fixed.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'