[whatwg] HTML5 History Management

[Mike Wilson]

Ian Hickson wrote:
> On Sun, 16 Aug 2009, Mike Wilson wrote:
> > Ian Hickson wrote:
> > > 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).

It seems we do indeed agree that the state object is for
storing state that could differ for multiple history entries
for the same URL, and what you are actually saying is that
you think this feature should not be used for "important"
state. I'm fine as long the former is true, and you are
free to have an opinion about the latter.

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

I still don't think this fixes my issues. I've described most
of these in the thread "Proposed changes to the History API"
so I'll wait until you reply to that before commenting
further here.

Best regards
Mike