[whatwg] Proposed changes to the History API

> I guess this is just a vision about what the developer really
> wants to do, or are you thinking of any solutions that would
> actually allow changing path (or query string) without loading
> a new Document?

The pushState function as currently specified allows you to do
precisely this.  History.pushState(obj, title, url) creates a new
history entry with the given URL, but doesn't load a new document.

>> ?It would further be nice if your comments weren't lost even if you
>> navigate away from the page.
>
> This is the way it works in most browsers, as the browser persists
> form field values when you navigate back and forth in history.

Right.  But the difficulty with this page in particular is that it's
structured such that it's difficult/impossible for the browser to
properly restore its form state after a crash.  Onload, the page
creates a <textarea> and populates it with the text of the patch.  So
if we crash then restore, the page won't have created the textarea by
the time the browser looks to restore the text.

One can imagine reworking this page to make it play nicely with
session restore as it currently exists, but what we really want is a
way to programmatically do the restore.

> ?click link to navigate from page1.html#a to page1.html#b:
>
> [snip]

I think this is pretty much what we want to do, except that we'd like
to let authors use arbitrary URIs instead of constraining them to
using URIs which differ only in their hashes, so we still want
PopState to fire on all loads, not like hashchange.

The idea of having an unload event similar to PopState is intriguing, however.

-Justin

Received on Thursday, 20 August 2009 11:31:15 UTC