Mike,
It does sound like we're asking for similar things. I think that my
personal proposal is history.replaceState() which does exactly
history.pushState() but pops the history stack first. Theoretically
this wouldn't be hard to implement and mirrors the relationship
between location.href = and history.replace().
Others: thoughts?
Nathan
On Aug 5, 2009, at 4:58 AM, Mike Wilson wrote:
Nathan Hammond wrote:
I should have stated this one with a goal: the ability
to ensure that the popstate event always fires with a
full understanding of the (app/page) state when
navigating through history. This would be lost when a
user manually changes the hash. [...]
Any other techniques for remembering data other than this
would still be a hack because, in and of itself, the data
stored are not uniquely tied to a particular history
state. [...]
Using sessionStorage I have the additional task of mapping
the stored series of states to a particular visit of the
(app/page) if the user visits the site again after
navigating away: example.com -> whatwg.com -> example.com
Hi Nathan,
I think I touched on the same need in my thread "html5
state handling: overview and extensions", see
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-June/020423.html
or
http://www.nabble.com/html5-state-handling:-overview-and-extensions-td240347
73.html
See the table on "SCRIPT-CONTROLLED STATE" at the end of
that mail. As you can see I am suggesting to add a state
construct for the missing Document state level. I'm just
back from vacation but I'm doing some more research and
hope to provide more information on that thread later
this month.
Best regards
Mike Wilson
