URLs without associated state objects are added
to the session history as the user (or script) navigates from page
to page.

A state object is an object
representing a user interface state.

Pages can addstate objects between
their entry in the session history and the next ("forward") entry.
These are then returned to the
script when the user (or script) goes back in the history, thus
enabling authors to use the "navigation" metaphor even in one-page
applications.

State objects are
intended to be used for two main purposes: first, storing a
preparsed description of the state in the URL so that in the simple case an author doesn't have
to do the parsing (though one would still need the parsing for
handling URLs passed around by users, so it's only a minor
optimization), and second, so that the author can store state that
one wouldn't store in the URL because it only applies to the
current Document instance and it would have to be
reconstructed 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.

An entry with
persisted user state is one that also has user-agent defined
state. This specification does not specify what kind of state can
be stored.

For example, some user agents might want to
persist the scroll position, or the values of form controls.

User agents that persist the value of form controls
are encouraged to also persist their directionality (the value of
the element's dir attribute). This prevents values from
being displayed incorrectly after a history traversal when the user
had originally entered the values with an explicit, non-default
directionality.

Entries that consist of state objects share the
same Document as the entry for the page that
was active when they were added.

Contiguous entries that differ just by fragment identifier also
share the same Document.

All entries that share the same Document (and that are therefore merely
different states of one particular document) are contiguous by
definition.

Entries in the joint session history are ordered
chronologically by the time they were added to their respective
session histories.
(Since all these browsing
contexts by definition share an event
loop, there is always a well-defined sequential order in which
their session histories
had their entries added.) Each entry has an index; the earliest
entry has index 0, and the subsequent entries are numbered with
consecutively increasing integers (1, 2, 3, etc).

Consider a game where the user can navigate along a line, such
that the user is always at some coordinate, and such that the user
can bookmark the page corresponding to a particular coordinate, to
return to it later.

A static page implementing the x=5 position in such a game could
look like the following:

<!DOCTYPE HTML>
<!-- this is http://example.com/line?x=5 -->
<title>Line Game - 5</title>
<p>You are at coordinate 5 on the line.</p>
<p>
<a href="?x=6">Advance to 6</a> or
<a href="?x=4">retreat to 4</a>?
</p>

The problem with such a system is that each time the user
clicks, the whole page has to be reloaded. Here instead is another
way of doing it, using script:

In systems without script, this still works like the previous
example. However, users that do have script support can
now navigate much faster, since there is no network access for the
same experience. Furthermore, contrary to the experience the user
would have with just a naïve script-based approach, bookmarking and
navigating the session history still work.

In the example above, the data argument to
the
pushState() method is the same information as would be
sent to the server, but in a more convenient form, so that the
script doesn't have to parse the URL each time the user
navigates.

Applications might not use the same title for a session history entry as the value
of the document's title element at that time. For example,
here is a simple page that shows a block in the title element. Clearly, when navigating
backwards to a previous state the user does not go back in time,
and therefore it would be inappropriate to put the time in the
session history title.

The pageshow event is fired when
traversing to a session history entry. The
pagehide event is fired when
traversing from a session history entry. The
specification uses the page
showing flag to ensure that scripts receive these events in a
consistent manner (e.g. that they never receive two pagehide events in a row without an
intervening pageshow, or vice versa).