[whatwg] History API, pushState(), and related feedback

[Mike Wilson]

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 closer to that 
> > of the other storage APIs, so I think it would be an 
> > advantage to use the same interface as well.
> 
> I don't see the relevance of storage APIs here. This isn't a
> storage model. It's more a callback model.

I disagree. Once an API persists state between page loads it 
deserves to be regarded as a storage API and not just a callback 
API.
The data objects supplied in pushState calls may be persisted for 
the lifetime of their browsing context (unless history entry is 
removed), just like data in session storage.


Invent new API pattern instead of reusing?
------------------------------------------

There should be good reasons why not to reuse existing API 
patterns.

Why is "pushState" inventing a new API pattern where a copy of
the state is forwarded through new methods and events, instead
of accessing it through a storage facade (see sessionStorage and
localStorage) as in WebStorage?

Why is "pushState" defining a more restrictive model to state
access (read once / write anytime) compared to WebStorage 
(read anytime / write anytime) ?

What use-cases are solvable in the current "pushState" model
but not in a WebStorage-style model? (see below for 
WebStorage-style example)

Ian Hickson wrote:
> Mike Wilson wrote:
> > Why not use the same API as in Web Storage:
> >   interface Storage {
> >     readonly attribute unsigned long length;
> >     getter DOMString key(in unsigned long index);
> >     getter any getItem(in DOMString key);
> >     setter creator void setItem(in DOMString key, in any data);
> >     deleter void removeItem(in DOMString key);
> >     void clear();
> >   };
> > and make the current entry's Storage instance always available
> > as f ex:
> >   interface History {
> >     readonly attribute Storage state;
> >   }
> > 
> > Then pushState's state parameter may be removed and there is
> > no longer a need for the replaceState method.
> 
> I don't understand how this would work. When does the history 
> get updated in this model?

The pushState method (without state parameter and possibly 
renamed) remains to create a new session history entry:

  function() {
    history.state.setItem("a", 1); // set on current history entry
    history.pushState(title, url); // create new history entry
    history.state.getItem("a"); // get from new history entry (null)
    history.state.setItem("a", 2); // set on new history entry
  }

> How do you know you've gone back in history? 

The popstate event (without state attribute) remains to inform 
us that history entry has been switched and that the corresponding
data is now available through history.state.


Best regards
Mike Wilson