I was recently invited to make a statement on WebMasterWorld about something in advanced Javascript at the edge of my understanding. I decided to cover fragment identifiers, something I have an odd obsession about:

There's a lot of cool stuff going on right now, standards-based graphics and sound foremost in my mind. But I'll focus here on something I've always found oddly fascinating: fragment identifiers and the quirky exploits around them. The humble "frag ID" is not exactly the pinnacle of the Ajax revolution, but it remains misunderstood and under-utilised by developers, and a feature which the browsers could do more to support. By design, fragment identifiers do just as their name suggests - they identify fragments of a document. Type in http://example.com#foo, and the browser will helpfully scroll to the "foo" element. However, they can be used for a lot more than that, thanks to peculiarities in the way they are handled by browsers.

Most importantly, by writing Javascript to change the fragment identifier, you're able to update the page URL, without effecting a page reload. This fact alone means - contrary to a popular Ajax myth - you can support bookmarking and history in an Ajax application. Furthermore, fragment identifier information is never sent to the server, unlike the rest of the URL, which leads to some interesting applications related to security and privacy. Another powerful application is interacting between iframes from different domain, something which is theoretically "impossible" in older browsers and tremendously important for embedding third-party widgets on web pages. And when I began working at Osmosoft, I discovered yet another application: providing startup context to web apps, such as TiddlyWiki, which run off a file:// URL...as they're unable to read conventional CGI parameter info.

I first researched this stuff for Ajax Design Patterns in 2005, and at that time, there were only a couple of scattered blog articles on the topic. Today, we can see the pattern in action in various high-profile places such as Google Docs and GMail. When I view my starred documents in the former website, for example, the URL is http://docs.google.com/#trash. That said, many developers still aren't using this feature to its fullest, and library support is somewhat lacking. It's encouraging to see IE8 has a new event for monitoring the fragment identifier, which suggests the story is not over for this rarely discussed property. </blockquote> This is certainly a hot topic, if not well understood or covered; shortly after I wrote it, I was amused to see the topic showed up on none less than Techmeme: The issue here is summarised in my statement: "fragment identifier information is never sent to the server, unlike the rest of the URL, which leads to some interesting applications related to security and privacy". These bloggers had noticed that google was (in some cases) changing their URL structure for searches to use hashes (#q=term) instead of traditional CGI params (?q=term). Thus, when the user clicks through from Google to your web page, you don't know what the user searched for. Another thing that recently arose is how easily you can retain fragment identifiers in bookmarking type sites. For example, if you submit a URL to Digg, it annoyingly strips the fragment ID. Whereas Delicious retains it. TinyURL retains it too, but their php "create" script removes it, according to a conversation I had with Fred, who created this tinyURL bookmarklet. I can see why sites wouldn't want to retain it, because it may well be just an in-page link, so it's a tricky issue. The main point being, fragment IDs - and design questions thereof - are alive and well.