[whatwg] pushState

[Kristof Zelechovski]

It is not customary for desktop applications to change the window title in
response to current state of the document it displays.  A Web browser is a
desktop application and it should not exhibit such behavior either.  The
place to store information about the latest user action is the Edit menu,
although it is optional.
The page content can change after page reload thereby making some elements
of session state useless or not applicable.  This would still be the same
page but different content.  You can still make arbitrary data into JSON
data using e.g. XPath or another moniker convention but, while technically
possible, it would hardly be a success in lack of application-dependent
intricate logic (consider e.g. the Alias Manager and its lame substitute in
Microsoft Windows).
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Jonas Sicking
Sent: Friday, July 25, 2008 11:45 PM
To: Ian Hickson
Cc: whatwg
Subject: Re: [whatwg] pushState

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?