[whatwg] pushState

[Ian Hickson]

On Fri, 25 Jul 2008, Jonas Sicking wrote:
> > 
> > The idea is to use this title in the session history. It's distinct 
> > than the <title> and document.title because when the session history 
> > might need to say something like "Mail - after opening 'compose 
> > mail'", "Mail - after typing paragraph ending in 'JSON-ifyable 
> > object.'", and so forth, while the whole time the actual page title 
> > just says "Mail - New Mail".
> 
> So the idea is that this is the title that we'd display for example in 
> the drop down where you can select a history entry to navigate to?
> 
> If so, why wouldn't you want document.title to also say "Mail - after 
> opening 'compose mail'" as well? Seems like good UI to keep the two in 
> sync.

My mail client just keeps the same title the whole time I'm using it. But 
seeing the name of my mail client six hundred times in a row without any 
hint as to what each entry means (in the session history) wouldn't be 
useful. So I guess my answer is no.

I think it makes sense that the entry you see in the session history and 
the entry you see in your OS pager would have different strings.

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.


> > > What is the purpose of the url attribute? Why would you want to 
> > > reload a separate page when returning to a given state, then what 
> > > was used to load that state initially?
> > 
> > If the Document gets discarded (e.g. it gets evicted from the 
> > bfcache), the URL allows the client to still pretend it has the state, 
> > allowing the server to regenerate it based on the data in the URL.
> 
> But why would you want to recreate the same document using a different 
> page than the page that originally created the document. I.e. if I have 
> a single page that I use to show various views, why would I all of a 
> sudden want to use another page to render one of those views just 
> because the user restarted the browser?

Consider an AJAX version of Bugzilla. Each bug page has a different URL. 
As you navigate from bug to bug, the URL should change to point to the 
currently showing bug. But you want to do that without actually doing a 
reload (changing the Document object).


> > 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.

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.


> > (The Location object should not be updated, however.)
> 
> Why not?

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.


> > > I would like to store the session states created using pushState on 
> > > disk so that the state can be restored in the event of a crash or a 
> > > restart. The only thing that would be needed to support this is that 
> > > the 'data' object is a string rather than a generic object. This is 
> > > because a generic object can't be serialized and saved to disk. 
> > > Actually, what would be even better is if the API accepted a string 
> > > or a JSON-ifyable object.
> > 
> > That's what the URL is for.
> 
> Then what is the point of the data object? It seems very bug prone that 
> the data object is just dropped on the floor if the browser is 
> restarted. I.e. we should recommend everyone not to use the data object 
> (except for some sort of cache?) since it will always fail to work if 
> the user restarts the browser.

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.

There are many ways of using this API, just like there are many types of 
applications. Some applications might be able to represent all state in 
the URL, others might not be able to represent any state there, others 
might be in between (e.g. GMail might be able to remember what e-mails you 
had checked in the data parameter, but would forget that if you bookmarked 
the page / reloaded the browser).


> > The data will, in many non-trivial cases, be some very complex object 
> > with actual Object references and pointers to DOM nodes and so forth. 
> > Imagine, for instance, a text editor using this. I don't think we want 
> > to require that the data be "plain structured data" (is there a term 
> > for this better than "JSON-ifiable"?), as that would preclude a number 
> > of complex cases.
> 
> 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.

The URL is optional. When it is omitted, the session history entry is just 
discarded when the Document is lost.

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.


> All in all, as the spec is written now it doesn't seem like 
> pushState(...) is providing a lot of value over window.location.hash = 
> "...". Other than that an event is raised on navigation, which we could 
> fix for setting location.hash.

Actually the spec also specifies the "hashchange" event, which IE8 
apparently supports. :-)


> My goal with this was to provide a clean API to avoid having to muck 
> around with location.hash trickery (as that really should be used for 
> other things), and that would work in the event of a browser restart. It 
> doesn't seem like the current API meets that goal.

The current API is written specificially to meet that goal for a variety 
of different applications with a broad set of requirements.

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