(See http://features.sheep.art.pl/BackButtonFriendliness for context:)

Instead of sending the new page content, respond to the POST HTTP request with a code 303 redirect to that page. The browser will then make another request, a GET this time, and save that in the browsing history: the POST will disappear from it as if it never was there, replaced with the new address. Now the users can use the “back” button safely… except for another problem.

that's not the problem.  we already do that.  issue is AJAX.  -efm

HTML5 offers two new JavaScript APIs, onReplaceState and onPushState, that may address most or all of the confusion that happens around the browser back button given our Edit, View, etc. tabs.

See http://warpspire.com/posts/url-design/ and search for "Everything should have a URL" (the following section "A link should behave like a link" also appears relevant).

  --John Abbe.....Fri Feb 11 08:02:26 -0800 2011

One design is what to do if the pagination or tab-changing someone is doing is in an inclusion. Maybe nothing, and only use these new features for tab changes of the main card? --John

  --John Abbe.....Fri Feb 11 08:04:41 -0800 2011

These may handle pagination better as well.

  --John Abbe.....Fri Feb 11 08:05:19 -0800 2011

http://www.jquery4u.com/plugins/history-back-button-plugins/

  --Ethan McCutchen.....2013-04-05 18:14:54 +0000