let’s say you want to access /#/foo, a.k.a. why you can’t access fragments from the server

It’s always great to learn something new. This was no exception. Perhaps you’ve heard of swfAddress. It’s a great open technique for getting intuitive back and forward browser button functionality that plays nice with flash. It seems like the holy grail, right?

And, really it is. One might not help but try to get the best of both worlds. House site content in XML. Have the flash consume the XML and use nifty swfAddress for navigation. Then output good ol’ XHTML via XSL (or tighly coupled server-side processing equivalent). And presto, two versions (for “free”), one flash, one not, both coming from the same data set.

Next you might want to join these two experiences together; seamlessly serving the appropriate experience to the appropriate agent.

Then you might devise an elegant system for getting inbound deep flash links - in the swfAddress style - to push via the server to the non-flash experience. And then you might use Javascript to push agents back into the deep flash section.

This situation helped to illuminate something previously unknown: the fragment anchor (the #foo) is not part of the request object sent by the browser. It is simply not sent. There exist some agents that have sporadic support for sending it, but it’s not part of the spec.

So sorry differently-abled agents (and bots), we can’t get you from a deep flash link to the appropriate page in the experience you can parse. You can still get there by clicking, but we can’t do it for you.

PS
There is an ingenious method proposed to at least reduce it to one click with many inline and css exposed named anchors with a link, but it would present it’s own degradation and maintenance issues.

This entry was posted on Thursday, June 5th, 2008 at 7:12 pm and is filed under seo, technique. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.