[whatwg] pushState

[Ian Hickson]

On Fri, 25 Jul 2008, Jonas Sicking wrote:
> > 
> > FWIW, the title parameter was added in response to requests in 
> > feedback from application authors, who didn't want to change 
> > document.title for this.
> 
> Requesting is easy. *Why* did they request this? Still seems like better 
> UI design to have this affect the title. The title of my mail client 
> changes to show what part of the UI I'm in. Currently it says "whatwg 
> for jonas at sicking.cc" indicating that i'm watching the whatwg folder on 
> the "jonas at sicking.cc" account.

Well to reuse the GMail example again, you might have entries like (in 
reverse chronological order, current entry at the top):

>> GMail - in:spam - checked all unread
   GMail - in:spam - unchecked all
   GMail - in:spam - checked 2 messages
   GMail - in:spam
   GMail - Inbox

...while the actual titles were (in the same order):

   GMail - Search - in:spam
   GMail - Search - in:spam
   GMail - Search - in:spam
   GMail - Search - in:spam
   GMail - Inbox

This seems like a reasonable thing to support.


> > > > Also, the URL can be used when bookmarking the page. It could also 
> > > > be displayed in the location bar.
> > >
> > > Hmm.. bookmarking is indeed tricky. If a site really want to support 
> > > bookmarking it seems like the best solution is to use the old hack 
> > > of setting location.hash.
> > 
> > The hash isn't sent to the server.
> 
> Why would you want to send something to the server?

Well again, consider Bugzilla -- Bugzilla knows how to generate a bug page 
if you go to that URL. You don't go to:

   http://bugzilla.mozilla.org/#bug20000

...and have AJAX fetch down the bug data.


> > Again, fwiw, the URL parameter was added in response to author 
> > feedback to the effect that only having control over the hash was 
> > insufficient for what they wanted to do.
> 
> Why?

So they can do what Bugzilla does, for instance.


> > > > (The Location object should not be updated, however.)
> > 
> > Changing it would introduce a gratuitous difference between legacy UAs 
> > and UAs implementing this feature, as well as complexity that I'm not 
> > sure I really want to have to test.
> 
> How exactly were you envisioning that people do fallback to legacy UAs?

There are already libraries that emulate this behaviour using nested 
iframes. The idea would be to simply have those libraries use pushState() 
if it was available instead. We wouldn't want unrelated things like the 
Location object changing just because they used the HTML5 feature, 
something which to the user of the library is an implementation detail.

(See, e.g., how Google Maps stores state in the back button without 
reloading today.)


> > The data object is for when the page still exists, so that the state 
> > can be updated on the fly, e.g. bringing back the exact same <video> 
> > element to the front, or whatever.
> 
> You can still do this, it's just that we won't encourage it using an 
> API.
> 
> You can just store your <video> or whatnot in some cache in some global 
> object. You could even store it in an array and store the index of that 
> array in the stored data object.
> 
> Storing objects in the history state isn't going to extend the lifetime 
> past that of the Document anyway. The UA is going to want to tear down 
> all stored objects when tearing down the Document since otherwise its 
> very likely that those objects would keep the Document alive, if nothing 
> else through the JS __parent__.
> 
> This actually means that even when not talking about a restart, in order 
> to better support long history chains where the Document is likely to be 
> evicted from the fastback cache, we should enforce that the data objects 
> be serializable (JSON-able).

I don't understand what you are proposing here.

Right now, when the Document is discarded, so are all the objects that 
were pushed using pushState(), as well as all the entries that don't have 
an explicit URL.

You are saying that over a restart you want to preserve even the entries 
that don't have a URL?

That doesn't make sense to me, after all, all the data those pages had 
loaded into RAM is gone now, they'd need to resinstantiate all the 
objects.


> > > But all those complex cases will fail on a browser restart. It is 
> > > much better if we encourage people to write stable code.
> > 
> > The original feature wasn't expected to work at all across a browser 
> > restart.
> 
> Well, consider it requested ;)

Right, that's what the URL parameter is for. Originally there was just the 
data argument, and no URL or title. We added URL to support the restart 
and bookmarking cases.


> > To use GMail as an example again, one might want to pushState() for 
> > every change of selected e-mails, but only pushState() with a URL when 
> > the search query changes.
> 
> Seems ok to me.

So, the same applies to restarts. You'd want the history of search query 
changes to survive, but the individual checks of the checkboxes don't need 
to -- and tracking them would in any case be way harder since the original 
DOM is gone by that point.


> Nor the case of long history chains.

Could you elaborate on this?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'