Monday, April 12th, 2010
The Future of History
Category: HTML
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:
-
-
// Push the state onto the history stack
-
function setState(state) {
-
window.history.pushState(state, '');
-
}
-
// Respond to a popstate event.
-
window.onpopstate = function(e) {
-
handleState(e.state);
-
};
-
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:
- The history of business intelligence and analytics and what comes next
- A brief history of Ajax
This year in review article charts the brief history of Ajax, which grew from the famous Jesse James Garrett essay in February 2005 to a technology... - Document History Function
4.8 rating from 13 votes
awesome photo and post title!
Thanks, but it’s just a variation of the original title (“HTML5 History is the Future”).
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?
You can check source of extjs History object (good example of cross-compatibility)
http://www.extjs.com/deploy/dev/docs/source/History.html
You can support the older HTML4 browsers and fix the HTML5 cross-compatibility bugs with History.js – https://github.com/balupton/history.js