Web browsers keep track of what documents have been loaded into a window and display Back and Forward buttons that allow the user to navigate among those documents. This browser history model dates back to the days in which documents were passive and all computation was performed on the server. Today, web applications often generate or load content dynamically and display new application states without performing new document loads. Applications like these must perform their own history management if they want to user to be able to use the Back and Forward buttons to navigate from one application state to another in an intuitive way. HTML5 defines two mechanisms for history management.
The simpler history management technique involves
location.hash and the hashchange event. This
technique is also somewhat more widely implemented at the time of this
writing: browsers were beginning to implement it even before HTML5
standardized it. In most browsers (but not older versions of IE),
updates the URL displayed in the location bar and adds an entry to the
browser’s history. The
property sets the fragment identifier of the URL and is traditionally
used to specify the ID of a document section to scroll to. But
location.hash does not have to be
an element ID: you can set it to any string. If you can encode your
application state as a string, you can use that string as a fragment
By setting the
location.hash property, then, ...