[whatwg] HTML5 History Management
mikewse at hotmail.com
Sat Aug 15 18:05:35 PDT 2009
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? 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.
> I don't think we should encourage cases where the same
> URL can correspond to multiple states, which this would
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?
But you may have a different purpose for these state
objects. I'm expecting to store things like step-for-step
state from wizard-like flows, or user interface state
similar to (but in addition to) the browser's own handling
of saving/restoring form field values and scroll position.
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.
It would be very interesting to hear about the scenarios
you have in mind, to be able to comment correctly. It
would be great if you could flesh out (or point to) a
concrete example of correct and intended usage of this
history state object mechanism.
> > [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"
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".
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? And does the popstate event really
supply the URL string in its .state member, instead of the
real object, in these cases?
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.
More information about the whatwg