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
