[whatwg] Proposed changes to the History API

[Jeremy Orlow]

On Thu, Aug 20, 2009 at 3:13 PM, Justin Lebar <justin.lebar at gmail.com>wrote:

> On Thu, Aug 20, 2009 at 11:20 AM, Jeremy Orlow<jorlow at chromium.org> wrote:
> > I see.  It makes more sense why you mentioned the session storage element
> > then.  Note that there has been some discussion about whether session
> > storage should survive crashes, but I know Safari and Chrome are
> currently
> > planning to _not_ serialize it to disk.
>
> I just did a quick test, and it appears that Firefox does save
> sessionStorage across browser sessions, but IE8 does not.
>
> Leaving aside the question of what the right thing to do is with
> sessionStorage,


The spec makes it clear that it's possible, but isn't session (in the
broader sense of the word) restore a UA feature, and not necessarily
something we need to all be the same on?  (Feel free to split this into
another thread if necessary.  :-)


> I think there are some serious benefits to saving the
> pushState'ed state across sessions.  Suppose I'm using a webmail
> client which uses this new API.  I click around to a few of my folders
> and messages and then close the browser.
>
> If the page wants the back/forward buttons to work when the browser
> re-opens, it needs to store all of the state for those history entries
> in the URI.  At the point that pages have to do that, we might as well
> not store a per-page state object.


Overall, I think preserving history API information when restoring sessions
is a good thing.  My only concern is whether web developers will program in
such a way that this works.  Unless ALL state will need to be either saved
in the history API or reconstructible from that information, bad things will
happen.  (Note that this was difficult if not impossible with the original
API, but your new proposal makes this quite practical.)

Do most web apps that use iframe hacks (for tracking history) come back
cleanly from a session restore?


> >  I still think we shouldn't force app developers to serialize everything
> to
> > strings.  Maybe we can just raise an exception if they try to set the
> > history state to something unserializable?  (I guess that's what you're
> > already doing?)
>
> Right now, I just serialize to JSON and throw an exception if that
> fails.  I don't have a problem continuing to do that, at least until
> we get the structured clone thing sorted out.


Yeah.  I think the structured clone semantics are the right way to go here
(but JSON is a good first approximation).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090820/2ff410a6/attachment-0002.htm>