Besides finally documentating all kind of interfaces browsers have used for years, like the window interface, HTML 5 also has some really cool innovations like the pushState function of the history interface. As argument it takes a DOMObject which basically allows you to save the DOM of a page in the browser's history. When only the DOM changes and not the URL as seen on Gmail this is a really nice feature. I can think of at least two companies who needed this feature for years: Q42 and Backbase.
In times of Ajax, this becomes really an important feature. Thanks again Anne!
Note that it is already possible to have correct back button behavior in current browsers with DHTML hacks.
True, I have been told these are very, very ugly hacks though so I guess such a function would be most welcome. By the way, in case of confusion, Ian Hickson came up with it.
Well, we can do that already at Backbase since last summer.
The thing is, once you got that, you want to do more. The next step is to be able to update the location bar as well, to allow for bookmarking. So as a next step the model needs to allow for that, otherwise it isn’t very satisfactory yet.
The goal is to support that using # fragment identifiers in the URL... Especially in Firefox this is quite trivial to use, because changing the hash automatically also updates the history, and if the back button is used, you can track it (although you need a timeout for that, afaik).
IE needs a bit more hackery, but it can be made to work as well. Dunno about Opera and Safari, but it would be nice if they behaved exactly like Firefox does.
Anyways, linking history to bookmarks makes a lot of sense. History just by itself is not that useful, and at least you would leave a lot of potential unused.
~Grauw
Changing the fragment identifier is nice, but it doesn't work very well with Google. What pushState should support is to be able to change the query string, without the browser leaving the page. The information in the query string allows the server to render the page in the correct state when a client comes along that doesn't support SPI (like Google).
(It would be nice to change more than just the query string, but that probably has unacceptable security issues.)
Grauw has the right idea. The back button not working is simply a symptom of a larger problem - that as far as the browser's addressing mechanism (address bar, history, bookmarks, etc) is concerned, it's still the same resource.
A Javascript method to add to the history list is treating the symptom, not fixing the problem. All the other symptoms, like being unable to bookmark the resulting page, still exist.
Laurens, Sjoerd, Jim, Ian is looking into it at the moment based on Sjoerd his suggestion on the mailing list. There are some issues I believe but at a guess I think something like this will make it into the draft.