Monday, April 12th, 2010

The Future of History

Category: HTML

<p>back-to-the-future

Kyle Scholz has a good overview HTML5 history (spec here). We’ve seen more and more apps adopt the fragment identifier pattern, where you get URLs like http://www.viewru.com/#Bonobo. Better than nothing, but Kyle observes there are several downsides:

Sluggishness

  • Executing a timeout function every 100ms won’t make your app any faster.
  • 100ms delay in responding to back button actions.


Browser compatibility

  • The solution above doesn’t work, for example, in IE 6-7, which won’t add a history event on a hash change. Really Simple History gets around this by adding an iframe and issuing a call to your server for every state change. Webkit browsers present different challenges.

Not a stack

  • Suppose your application transitions from A->B->C. Can it transition directly back to A?

HTML5 offers a cleaner solution:

javascript
< view plain text >
  1. // Push the state onto the history stack
  2. function setState(state) {
  3.   window.history.pushState(state, '');
  4. }
  5. // Respond to a popstate event.
  6. window.onpopstate = function(e) {
  7.   handleState(e.state);
  8. };

Not only can you move back and forth between state, but you can also set URL and page title with this API. (The fragment ID was traditionally used because it was the only way to set the URL without causing a page reload.) Comparing the new techniques to traditional fragment ID hackery:

  • Content is crawlable: A developer may express all crawlable states of their application as valid URLs.
  • HTTP-Referer is meaningful: The referrer can reflect the latest state of the application and show or hide any information to/from 3rd parties, at the developer’s discretion.
  • Bookmarks can be handled in a single fetch: Since application state can be expressed in a URL, it’s possible to service a request for the application and state in one request/response.
  • Can use a single URI scheme to cover new and old browsers: Since information is encoded in URLs instead of the location hash, modern and legacy users can share bookmarks and links.
  • Audible “click” in IE? Okay, I don’t know about this one, but it makes sense that programmatic operations on window.history would not have an audible side effect, right?
  • Related Content:

    Posted by Michael Mahemoff at 5:52 pm
    5 Comments

    ++++-
    4.7 rating from 14 votes

    5 Comments »

    Comments feed TrackBack URI

    awesome photo and post title!

    Comment by tiagosimoes — April 12, 2010

    Thanks, but it’s just a variation of the original title (“HTML5 History is the Future”).

    Comment by Michael Mahemoff — April 12, 2010

    So I’m left wondering, what is the current best practice for a HTML4.01 web application that needs to have in-page history for IE7+, FireFox, Safari, Chrome, Opera and not bothering with in-page history for IE6-
    Any recent blogs in the past year that discusses this?

    Comment by GordonStanton — April 13, 2010

    You can check source of extjs History object (good example of cross-compatibility)
    http://www.extjs.com/deploy/dev/docs/source/History.html

    Comment by botmonster — April 15, 2010

    You can support the older HTML4 browsers and fix the HTML5 cross-compatibility bugs with History.js – https://github.com/balupton/history.js

    Comment by balupton — April 14, 2011

    Leave a comment

    You must be logged in to post a comment.