[whatwg] pushState

[Ian Hickson]

On Tue, 29 Jul 2008, Jonas Sicking wrote:
>
> I'll check with the ECMA Script folks, but this one might be an 
> alternative to link to:
> 
> http://wiki.ecmascript.org/doku.php?id=es3.1:json_support
> 
> State that the object passed as 'data' is passed to JSON.parse with the 
> second argument not specified. Any exception thrown is forwarded out to 
> the caller of pushState as usual.

Interesting, thanks. Doesn't really define it clearly though. :-(


> > > When entering a SH state for which a Document has been destroyed, we 
> > > load the URL associated with that SH entry. After the 'load' event 
> > > for the Document has fired, and if a data object was provided in the 
> > > pushState call for the SH entry, we fire a PopStateEvent event 
> > > containing the data stored for the object.
> > 
> > How would this work with bookmarking?
> 
> Just as specified (or at least intended) in the spec right now.
> 
> Say that the user starts on page1.html
> 
> <bookmark>   (bookmarks page1.html)
> pushState("title", "data")
> <bookmark>   (bookmarks page1.html)
> pushState("title", "data", "page2.html")
> <bookmark>   (bookmarks page2.html)
> 
> Additionally, a UA is free to add the ability to store the data 
> parameter in its bookmark storage. For example firefox under some 
> circumstances flags URIs in the bookmark store as POST URIs, i.e. they 
> should be fetched with POST rather than GET (this is specifically for 
> search engine bookmarks). Similarly the data can be stored alongside the 
> URI for the bookmark, however this is optional, just like the fastback 
> cache.

The problem I have with this is that it increases the number of possible 
user-visible behaviours and failure scenarios:

 - same Document, script knows how to handle data.
 - different Document, script knows how to handle data.
 - same URL, different Document, data ignored.
 - different URL, different Document, script knows how to handle data,
   but copying URL fails to work as expected.
 - different URL, different Document, data ignored.

If we want to not allow same-Document entries to share state using actual 
pointers into their state, I'd rather drop the data thing altogether, and 
only use URLs. That way the author doesn't have to worry about having 
multiple ways to carry state data around, and there's a clean way of 
migrating from today's hash-only approach -- keep using the hash.

What I'm suggesting gets rid of the:

   void pushState(in DOMObject data, in DOMString title);

...and makes the only pushState() definition be:

   void pushState(in DOMObject url, in DOMString title);

When the user navigates the session history amongst entries with different 
URLs that happen to have the same Document because they were added with 
pushState(), we fire an event. We drop all the stuff about the "data" 
argument. We make pushState() change the UI and the Location object. (The 
event we fire could be an event that we say always fires just after onload 
as well, so that if a page supports this stuff, it'll always support it 
even when you go straight to that URL.)

This way, bookmarking and copying URLs all works fine.

What do you think?

What do other people think? Is losing the ability to link to JS objects 
within the Document itself a problem?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'