http://www.robertpenner.com/experiments/flas/backbutton.zip

Also, don’t think it was rocket scince for us to do. Don’t get cocky ;-).

@michael: you have some valid points, but please see also the big picture: nobody says you should record every single click on every menu item; that you could do that is something completely different. (BTW: I believe I “know” you from Intellij scene?)

I think that article Mark provided was just to show how you could implement back button functionality: using selectbox to explain this was maybe bad idea because people are to much picking on it: “why would you want to save selectbox state”. Well, you don’t, imagine it is something else (e.g. a page you loaded). Choice was made to keep article simple and understendable, without to much JS code.
-m.j.milicevic

If the application developer is going to go through the trouble of implementing a back button functionality, it shouldn’t be that much more work to add in the server side code on the degraded page to deal with such events, especially considering how much effort has to be put into other aspects of the application, such as form submission and processing, in order for those to also be degradable.

From a comment: “A single-page interface (loading new data into an existing page) is only possible when JavaScript is enabled, because it depends on the XMLHttpRequest object. The idea of a single-page interface is that the page is not reloaded when new information is displayed, so the URL cannot change, otherwise you get a page reload.” — Partially true.

Let’s draw a line between single-load interface and single-address interface. Single-address interface does not have to be single-load. As the article shows, single-load interface does not have to be single-address interface as well.

The fact that browser adds every resource to a history list works well for hyperdocuments but usually a nuisance for web applications. I found a way to get rid of this behavior using redirection. Now Ajax provides it for free, great, use it. Instead if it, people try to reimplement hideous history list in Ajax. Incredible.

Don’t get me wrong, I am all for proper page reload and for navigating back and forth, but only when it makes sense! Say, you have a menu on a webpage. You select one item, than another, then another. Should all three actions be recorded as three locations in history list? Should I click Back three times to leave the page with the menu? Come on, this is ugly.

The same with form submission. If I made five attempts to submit a form, should I click back five times (sorry, six times) to leave the form? Would not it be easier to click only once? Each form submission is not a separate page, it is just an attempt to submit the *same* page.

Sometimes Back button is needed, but not always!

The idea of a single-page interface is that the page is not reloaded when new information is displayed, so the URL cannot change, otherwise you get a page reload. Therefore, using the hash (#) is the only way to dynamically add information to the URL.

Yes, you are right, this is the simple fact I was missing. Indeed, if you use the location() method, you will force a reload. So the url has to stay identical.
During a long instant, I was thinking that you were using location() without having the browser reload… but hey, this is not what the function does (but it would be nice if it could).

I finally get it. Thank you for the extensive explanation ,)

If JavaScript is switched off, you can only use a multi-page interface. In this case, you need to load a new URL to display new information. Of course, you can still use AJAX features with a multi-page interface, but if you want to use the back-button to navigate between different AJAX states you still need the hash URL approach: this doesn’t degrade, but if you can’t access the AJAX functionality, what is the use of navigating between AJAX states?

So the two approaches are separate, and there’s not much we can do about that: that’s the nature of the Web.

I am perhaps wrong, but I do not get the benefit of separating the two?

Your web browser is not compatible with the primary Backbase site. Find out which browsers are supported at the Compatible browsers page.

when you try to access the forum. Great idea, you just told me that my browser sucks – here, buy something!

Thanks, but no thanks. There are better ways of playing nice with browsers.

i.e. if you put the “real” location in the fragment portion (after the dash), then this information is only availlable client-side, hence only if javascript is enabled.

what if you bookmark this, deactivate javascript and try to come back? the local information is not transfered to the server => no degradation.

For it to be degradable, the state=location should be stored in a form transferable to the server without javascript.

In deed, in the forum example, why would you store the #forum/forum.html%3Fid=4[1] as a client-side information. It is something equivalent to a server-side information (the notation in deed reflects that).

This back functionality is important, but there is probably a better way to implement that in a “progressive enhancement” way. (see for example domscripting post on that matter)