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