It seems the big questions here are whether to regard pushState
as a storage API, and whether to invent new API patterns instead
of reusing existing ones.
Is pushState about storage?
---
Ian Hickson wrote:
Mike Wilson wrote:
the semantic contract is coming closer and
On Wed, 10 Feb 2010, Justin Lebar wrote:
That's not quite how I would describe it. It's more that each entry in
the session history has a URL and optionally some data. The data can
be used for two main purposes: first, storing a preparsed description
of the state in the URL so that
On Thu, 18 Feb 2010, Mike Wilson wrote:
Ian Hickson wrote:
On Fri, 22 Jan 2010, Mike Wilson wrote:
I'll keep this short as there is more recent discussion:
2) The pageStorage object is one incarnation of [a key
value store] solving the dependency problem that appears
when
Ian Hickson wrote:
On Fri, 22 Jan 2010, Mike Wilson wrote:
I'll keep this short as there is more recent discussion:
2) The pageStorage object is one incarnation of [a key
value store] solving the dependency problem that appears
when different components want to save data to the
On Thu, Jan 14, 2010, Hixie...oh dear.
On Tue, 18 Aug 2009, Justin Lebar wrote:
(An attempt at describing how pushstate is supposed to be used.)
That's not quite how I would describe it. It's more that each entry in the
session history has a URL and optionally some data. The data can be
On Fri, 22 Jan 2010, Mike Wilson wrote:
I'll keep this short as there is more recent discussion:
2) The pageStorage object is one incarnation of [a key
value store] solving the dependency problem that appears
when different components want to save data to the single
session history
Ian Hickson wrote:
On Wed, 19 Aug 2009, Mike Wilson wrote:
Currently, the design with an immutable state object and
the PopEvent
and HashChange events triggering at somewhat insufficient
timings, makes
it hard to build the things I'm thinking about.
IMO you need:
- an event
