[whatwg] Proposed changes to the History API

[Mike Wilson]

Justin Lebar wrote:
> [...]
> Notably unsupported by this API is support for pages altering their
> saved state.  For instance, a page might want to save a text box's
> edit history to implement a fancy undo.
> [...]
> We'd probably want to fire PopState on all loads and history
> navigations, since any document might have a state to pop

Right, this is exactly my thoughts on the API as well, as we 
started discussing recently, see:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022087.html
| Though, when taking a more thorough look at what is 
| spec:ed, it seems these use cases are indeed not supported, 
| due to state update limitations and how events are ordered.

Currently, the design with an immutable state object and the
PopEvent and HashChange events triggering at somewhat 
insufficient timings, makes it hard to build the things I'm
thinking about. 

IMO you need:
- an event each time you're *leaving* a history entry (in 
  addition to HashChange triggered when entering one)
- allow updating existing state entries
- shift the whole state entry model so that state entries 
  belong to history entries, and are not logically inserted 
  "between" them (this is actually a very important 
  distinction)

I'm hoping Ian will come back with the use cases he has in
mind, as I am as of yet not clear on what he wants, or does
not want, to support with the pushState model.

Best regards
Mike Wilson