Fragment Navigation

The Frames Problem

As the Internet birthed and quickly started evolving we developed a system called 'frames' to build websites from. And just as we all adopted the method into our websites we just as quickly realised the fatal flaws in the concept and started digging them back out.
Today, as the Internet has evolved from static websites into powerful applications we are quickly embracing the technology known as 'AJAX' (or XHR) and now risk making the same deadly mistake as frames. AJAX allows us to create sub-calls to the server behind the scenes and update the page without reloading. This gives us a new interactive power and, alike frames, a way to completely update the page.. without altering the address bar. This mistake prevents spiders from indexing your data and removes the ability for people to copy/paste URLs or bookmark pages.

The Solution

If you want to dodge the mistake before it devours you applications then you will need to take a look at the solution: fragment navigation.

Fragment navigation (or hash navigation) utilises the fragment part of the URL (the part after the hash) to allow for URL changes without reloading the page while giving the ability to have the URL re-entered and maintaining the current status of the page. The best example for this would be from our Internet pioneers - Google. If you have a Gmail account, take a quick look at the address bar when using Gmail. Note the fragment as you navigate between sections of Gmail and note how the page is loading via AJAX, not complete new page loads.

Why It Works

The fragment was designed so you could create anchors in the document. Anchors were a concept created to quickly move between sections of a single long page, a 'table of contents', so to speak. The idea was that only the client takes notice of the fragment, and it never sends the fragment to the server. That way, the client can load a fragment, move the page scroll position and not have any interaction with the server. This point allows us to alter the fragment with JavaScript and not make any request from the server for new page information.

This was NOT what the fragment was designed to do, and as such it doesn't work perfectly, so we need to carefully work around a flaw in this system if we are to create a fully-functional fragment navigation.

How It Works

For fragment navigation to work properly, you need to synchronise both the updating of the address bar with your XHR calls. Although the process may be a little gratuitous later in this article, you will need to create a JavaScript event on your links, with your links including the new URL (which will only be a change in the fragment). This allows you to trigger the JavaScript or XHR process and change the URL at the same time.

The Flaw

The next process is to ensure that the page state is preserved when the page is loaded the first time. Here-in lies the ultimate shortfalling in this process as the fragment is NOT passed to the server on the first page load. Additionally, a fragment might not even be in the URL when loading the first time.

If there is no fragment in the URL, you need to append one before loading the page. If you don't, you may face page-reload issues later in the process.

On first load, the server should return a page without state information. If you want to follow the Gmail approach, a loading screen is a good idea at this stage. Once the page is fully loaded (your loading screen shows zero progress) you can begin making XHR calls to the server with the fragment included in the data sent, now that JavaScript can read the fragment and send it to the server as POST or GET data.

Once all required state information has been loaded, you can remove your loading screen and display the page in it's fully-loaded state that has utilised the fragment.

The Back Button

Putting JavaScript actions on all your links only covers half the problem. The user may press "back" or "forward" on the browser, which will alter the fragment but no JavaScript event is fired to notify your application that a change has been made. Your application will then neglect the back button press and behave incorrectly.

The solution here is make-shift due to a lack of browser functionality, however the latest (at the time of this writing) version of FireFox and IE8 have added an event that is fired when the fragment is altered. This removes the need for hooks on all links, however there is insufficient browser support for it to be a liable solution.

Polling, unfortunately is the only answer. Setting a polling interval of 1/4 second is very suitable, well below anything noticeable to the human eye. If you set up a monitor to look for fragment changes then you can fire your XHR/JavaScript actions when arbitrary changes to the URL are made, either via browser history navigation or manually altering the URL - or if you forgot to put a JavaScript hook on one of your links. This will tighten your navigation to a completely solid system.

Ideally, adding JavaScript events on every link, utilising the new event on fragment changes and having a polling system is the perfect way to ensure that your application responds as quickly and fluidly as possible. The end result is a fast, responsive and user-friendly system that can be bookmarked.