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

> On Thu, Jan 14, 2010, Hixie...oh dear.

>> On Tue, 18 Aug 2009, Justin Lebar wrote:
>> (An attempt at describing how pushstate is supposed to be used.)

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

> If the Document is not recoverable, then recovering the state object makes
> little sense, IMHO. We should not be encouraging a world in which the
> meaningful state of a page is described by more than its URL. However,
> it's a UA decision whether to enable this or not.

Yes, but we want to make sure we're making the right UA decision. :)

I approached this from a different angle: 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.

I think you have a strong argument above.  On the other hand, the fact that
history entries X and Y are in fact the same Document is itself page state
which isn't stored in the URL.

> On Tue, 5 Jan 2010, Justin Lebar wrote:
>>
>> I think this is correct.  A popstate event is always dispatched whenever
>> a new session history entry is activated (6.10.3).

> Actually if multiple popstates are fired before 'load' fires, all but the
> last are discarded, and the last waits until after 'load' fires to be
> fired. But otherwise yes.

Oh, interesting.  I didn't even notice that popstate is async again.  Good to
know.

-Justin

Received on Wednesday, 10 February 2010 22:54:28 UTC