[whatwg] History API, pushState(), and related feedback

[Ian Hickson]

On Wed, 10 Feb 2010, Justin Lebar wrote:
> > 
> > That's not quite how I would describe it. It's more that each entry in 
> > the session history has a URL and optionally some data. The data can 
> > be used for two main purposes: first, storing a preparsed description 
> > of the state in the URL so that in the simple case you don't have to 
> > do the parsing (though you still need the parsing for handling URLs 
> > passed around by users, so it's only a minor optimisation), and 
> > second, so that you can store state that you wouldn't store in the 
> > URL, because it only applies to the current Document instance and you 
> > would have to reconstruct it if a new Document were opened.
> > 
> > An example of the latter would be something like keeping track of the 
> > precise coordinate from which a popup <div> was made to animate, so 
> > that if the user goes back, it can be made to animate to the same 
> > location. Or alternatively, it could be used to keep a pointer into a 
> > cache of data that would be fetched from the server based on the 
> > information in the URL, so that when going back and forward, the 
> > information doesn't have to be fetched again.
> > 
> > Basically any information that is not information that you would not 
> > include in a URL describing the page, but which could be useful when 
> > going backwards and forwards in the history.
> 
> Can we publish this somewhere?  This is crucial and not obvious.

Done.


> Does it make sense to persist the fact that two history entries with 
> (potentially) different URLs correspond to the same document across 
> session history?  If pushState is supposed to replace using the hash to 
> store data, then we should persist this fact across session restores, 
> right?  But then we have to also persist the state data; otherwise, if 
> the page used pushState with no URL argument, it wouldn't be able to 
> distinguish between the two states.

The spec says you should store the relationship:

| Entries that have had their Document objects discarded must, for the 
| purposes of the algorithms given below, act as if they had not. When the 
| user or script navigates back or forwards to a page which has no 
| in-memory DOM objects, any other entries that shared the same Document 
| object with it must share the new object as well.

Consider what happens with navigation around a document with just a hash, 
for instance. I think that makes sense. However, pages might get mighty 
confused that they are getting state objects that no longer make sense, if 
they're not careful.

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