[whatwg] pushState

[Jonas Sicking]

Ian Hickson wrote:
> On Fri, 25 Jul 2008, Jonas Sicking wrote:
>> What is the purpose of the 'title' argument? Is the idea that the UA 
>> will show that where it usually shows the <title> of the page? If so the 
>> title isn't purely advisory as it should probably affect document.title 
>> as well. This would seem like a good idea to me.
> 
> 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.

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

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

Ideal would be if there was a way to pass parameters to a page as part 
of a URI. Currently the query parameters are aimed for the server, and 
the fragment identifier is aimed for where to scroll. I'm not sure if 
there is syntax that would work for browsers today.

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

Why not?

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

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.

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.

/ Jonas