The Ajax URL Trick, how Apple (and others) do it

A well-known technical limitation of Ajax is the inability to update the URL in the Browser’s address bar without having to reload the whole page. While this is basically a good idea (imagine the phishing opportunities by pretending my site’s URL is apple.com), there are some Web2.0 use cases where this may be quite useful.


Imagine a simple guestbook webapp where all posts are simply displayed vertically beneath each other. Since this could generate a huge page, it’s a good idea to use a paging mechanism with prev and next links. To ajaxify that application, we’ll put all comments in one containing div element and only update the content of that div when clicking a prev or next link. Obviously, the URL will never change while scrolling through the guestbook and always be like http://mike.meessen.biz/guestbook/index.php.

Thats fine… but what if there’s an interesting comment on page 67 which I want to share (perhapps with a buddy through IM)? In a Web1.0 context, I’d just copy/paste the URL while having page 67 displayed. That URL would have a POST argument like ?page=67 allowing that URL to point exactly to the content I saw when I was grabbing it. However, with my ajaxified version, I don’t have this parameter and thus everyone would have to scroll through the pages to find the post I wanted to share. Even if I’d display direct links to each page, I’d still have to tell my buddy to go to page 67 and to look at the 5th post on there. Permlinks are a workaround but are far less intuitive and look different on every page whereas the URL always sits in the browser’s address bar and just waits to be grabbed. Wasn’t Web1.0 much simpler?

Now imagine it would be possible to rewrite the URL so that whenever I click one of the prev/next links, the URL displayed in the browser would contain all parameters needed to get exactly the same state I’m in when copying the URL. Bookmarking is exactly the same and suffers from exactly the same issues.

Note that I’m assuming we’ve got web developpers that know what they do, how they do it and what implications this URL manipulation may have in terms of tech and coherence. Well, unfortunately for those Web developpers, such a direct URL manipulation isn’t possible. At least not without having the browser arbitrary reloading the page. Many forums where this question rose up ended up with that conclusion.

However, if you take a look at this page (taken from Apple’s brand new .Mac WebGallery WebApp), you’ll notice that, when clicking on the little color dots on the bottom right, the URL changes, but the page doesn’t reload.

Now, how did they do that?

Well, basically it’s like every Web2.0 solution: hack the hell around everything. It took me some time to figure out, but here’s the deal: There is a certain part of the URL you may “legally” update without having the browser reloading the whole page. It’s the part after the hash (#), originally designed to specify a certain point on a large page. You’ll be able to change everyting after that hash at your will using JavaScript like this:

document.location.hash = "page=67";

On the page “http://mike.meessen.biz/guestbook/index.php”, that would result in the following URL being displayed in the browser:

http://mike.meessen.biz/guestbook/index.php#page=67

From here, it’s kinda simple: put your http-POST-like argument list after the hash, make your application recognize these after-hash arguments when the page is loaded (which will be hack-the-hell-around again) and you’re done.

Pretty cool, huh?

 

[ Update ]

With HTML5’s History API, you can achieve even more native-looking URL manipulations without the need for a ‘#’ in the URL 🙂 Note though that the browser needs to support the History API (the major ones already do), and that you still need to provide the “real” URLs behind the ones you “fake” server-side to achieve true bookmarkability. Check it out: http://diveintohtml5.org/history.html.

 


Sources:

http://www.thescripts.com/forum/thread170365.html
http://gallery.mac.com/emily_parker
http://diveintohtml5.org/history.html

 

 

 

 

 

 

 

 

 

Advertisements

2 thoughts on “The Ajax URL Trick, how Apple (and others) do it

  1. Any Idea on how well (or not so well) this technique works with regards to SEO and Search Friendliness? My thought is that most search engines throw out those tags and would make it impossible for a spider to crawl a site for content.

    The other thought is that you have real physical links (for spiders and non-javascripters) that return false if javascript is supported. That way those who have javascript can browse a happy AJAX site and still have link backs to share with others and spiders can still crawl the site.

    Sound feasible?

    Like

  2. Yes, indeed. SEO / Search friendliness would suffer from this method if one doesn’t actively pay attention to it.

    I’m afraid I didn’t get your other thought quite well. What do you mean by “real physical links”? Do you mean something like:

    <a href="[physical link]#new_hash" onmousedown="function() returning false;">

    ?

    You’d have to test how the different browsers behave with such a link, but to give a quick rough answer: yes, sounds feasible. And since a real link (not just javascript) appears in the html, search engines might get it right, too.

    Like

Comments are closed.