[whatwg] History API, pushState(), and related feedback
ian at hixie.ch
Thu Apr 8 18:50:43 PDT 2010
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.
> 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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg