IE8, HTML5 and Ajax Navigation: The future of Really Simple History

Brian Dillard, Wednesday, March 19, 2008 @ 2:23 pm

IE8

Speaking of Really Simple History....

While perusing John Resig's widely discussed analysis of IE8, I was surprised by his lack of fanfare when discussing its support of HTML 5's Ajax navigation module. This is a major development in the arena of Ajax history and bookmark management.

John's comments:

HTML 5: window.location.hash

Already supported fairly well by most browsers. Modifying window.location.hash changes the page URL and adds the page to the history (allowing for back-button simulation in Ajax applications). IE went a step further and broadcasts the hashchanged event (the first browser to do so, as far as I know).

For those who don't curl up in bed at night with WC3 specs, here's what the latest HTML 5 working draft (dated 18 March 2008) has to say about the hashchanged event:

4.7.2

6. If the specified entry has a URI that differs from the current entry's only by its fragment identifier, and the two share the same Document object, then fire a simple event with the name hashchanged at the body  element, and, if the new URI has a fragment identifier, scroll to the fragment identifier.

For more context, you could also turn to one of Microsoft's IE8 white papers: Better AJAX Development, specifically the section on "Ajax Navigation."

AJAX Navigation enables users to navigate back and forth without leaving the AJAX application and could be used navigating a page without performing a traditional full navigation. This allows Web sites to trigger an update to browser components like the address bar by setting the window.location.hash value, firing an event to alert components in the page and even creating an entry in the travelog.

Ideally, standards-compliant Ajax navigation should obviate the need for Ajax history libraries such as Really Simple History. To compare fantasy vs. reality, I whipped up a test page.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

<head>

	<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>

	<title>Ajax Navigation Test Page</title>

	<script type="text/JavaScript">

		var hash = -1;

		var changeAnchor = function() {
			hash++;
			window.location.hash = hash;
		}
		window.onhashchange = function() {
			alert("Really Simple History, your days are numbered!");
		}

	</script>

</head>

<body>

	<a href="javascript:changeAnchor();">change anchor</a>

</body>

</html>

(For a fancier version, check out this post from a .Net developer.)

To make sure I got accurate results, I dropped my test file into my local Apache root rather than running it from a desktop file. The result? Every time I clicked on my "change anchor" link, I got the expected JavaScript alert. Every time I clicked on the back or forward button, ditto. Heck, I got the alert even when I manually changed the hash value in the address bar.

So does that mean Ajax history and bookmarking libraries are on their way out? Close, but no cigar. The advent of the hashchange event does simplify things, but it doesn't eliminate the need for RSH and its ilk altogether.

The good news is that Microsoft is finally moving forward. IE6 and IE7 are the bad children of the modern browsers; unlike Opera, Safari and Firefox, current versions of IE will only add an entry to the history stack when you perform a bunch of mojo with a hidden iframe. With its new beta, IE jumps to the front of the class. Why? Because although Opera, Safari and Firefox have created history entries from hash changes for some time now, they don't yet throw a hashchange event. You still have to fake it by polling with setTimeout or setInterval.

Without the need to manipulate iframes or poll for hash changes, history management in IE8 should be a much simpler affair. You'll just need to maintain an internal cache of all history events you've created programmatically so your listener can tell the difference between hash changes that you're creating vs. ones you're responding to. Pseudo-code for a real-life hashchange listener would look like this:

window.onhashchange = function() {
	for (var i = 0, j = myHashStack.length; i < j; i++) {
		if (window.location.hash == myHashStack[i]) {
			//respond to an event;
			//this is a user-generated hash change
			break;
		}
		//otherwise, do nothing;
		//this is a new hash value we're creating programmatically
			return;
		}
	}
}

Of course, such simplified code will thus far work only for IE8. Other browsers will still require polling and other browser-specific hacks. Even after all browsers support the hashchange event and all non-supporting browsers fade into obscurity, Ajax history management will still play a role. For one thing, we'll still need a mechanism for our Ajax apps to associate state information with a given hash value (assuming, of course, that the hash token itself doesn't contain all the state information you need).

Right now, RSH accomplishes this with a hidden textarea. In the future, though, offline storage mechanisms will probably play the textarea's role. Once we get to the point where offline storage and the hashchange event are universal standards, Ajax history management will morph from a collection of hacks to a collection of convenience methods for native browser capabilities. Let's hope that time is sooner rather than later.

There is some bad news on the Microsoft front. Like its predecessors, IE8 only maintains history entries for a page's hash values while you're still on the same root URL. You can change the hash on a page 10 times and see 10 different entries for it when you view the history menu (by holding down the arrow icon next to the back and forward buttons). But the minute you navigate away to Google and look at your history menu again, you'll see only one entry for page with all the hash states. The additional hash states won't reappear in your history menu until you navigate back to the hash-crazy page. This makes for an extremely confusing user experience. Dare we hope this is something the Explorer team might change before the final release?

Related Services:
Ajax Rich Internet Applications, Custom Software Development

Related posts:

  1. Really Simple History: Progress on title updates
  2. HTML5, Ajax history management, and The Ajax Experience 2008 Boston
  3. A quick update on Really Simple History
  4. Really Simple History: Title updates may be more trouble than they’re worth
  5. Really Simple History: Onwards and upwards

Topics: , , ,

Software Development Software Development

Comments: 5 so far

  1. Thats all great, but what about updating location.search, I find that much more interesting than modifying the hash.

    Comment by Henrik, Thursday, March 27, 2008 @ 5:23 am

  2. thanks

    Comment by prefabrik, Thursday, April 3, 2008 @ 10:05 am

  3. I am not finding the HTML5 spec excerpt that you quoted coming from http://www.w3.org/html/wg/html5/
    Section 4.7.2 in the spec quoted is about elements.
    Please advise.
    Thanks,
    Michael

    Comment by Michael S. Scherotter, Tuesday, July 15, 2008 @ 7:44 am

  4. It would also be nice if the hash value was passed over the wire to the server as well (just like query params). There are many circumstances where the hashes invisibility on the server side can be problematic.

    Comment by Noel, Friday, July 18, 2008 @ 3:25 pm

  5. Hello,
    I am using RSH for my website, I have a problem that in firefox when I keep site inactive for a couple of hours, navigation stops if i clicked any link that start with “#/url”.

    I used timer (i.e. window.setTimeout) running that monitors changes to the document.location. When it sees a change, it fires event onHistoryChange that catched in navigation.js and switch to appropriate pane.

    In FireFox, if site is left without an activity for a few hours, such links stop working.

    What would be the problem.? Any guess.?

    Comment by vikas, Friday, February 27, 2009 @ 10:16 pm

Leave a comment

Powered by WP Hashcash

Launch: Pathfinder Newsletter

    Get a monthly update on best practices for delivering successful software.

    Subscribe via email


    Subscribe via RSS      RSS icon

Categories

Topics

Blogroll

Search

WordPress

Comments about this site: info@pathf.com