[whatwg] pushState

On Sun, 3 Aug 2008, Jonas Sicking wrote:
> >
> > 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.
> 
> I'm actually more worried about the URL thing causing bugs than the data
> thing.
> 
> * To avoid bad user experience behavior the site has to send almost
>   exactly the same markup for both URLs, i.e. both for the page that
>   called pushState, and for the page served for the URL in the URL
>   argument in the pushState call.

Equivalently though, to avoid a bad experience, a site will have to 
provide a statically generated URL version anyway, even if data is 
provided, to handle the bookmark case.


> * Entering a URL that is results in a 404 (or any other non-succcess
>   value). This works fine when pushState is called, but fails on reload.

Equivalently, if the author screws up the data handling but gets the right 
URL, then things will work fine in static browsing (with no JS) but as 
soon as you enable JS in a browser that does pushState(), things will 
break if you go back.


> Additionally, if we allow the data parameter to be preserved across Document
> recreations there is also:
> * Both URLs have to react the same way when a popstate event is fired.

I am proposing getting rid of popstate and the data altogether.


> So I think we should either drop the URL argument entirely and say that 
> URL transitions are too risky.

This would fail to address one of the core use cases, namely 
bookmarkability, so this isn't really an option.


> Or we should leave the spec as is (but require that data is 
> serializeable) and just encourage people not to transition between 
> wildly different pages.

Well I'm fine with leaving the spec as is, obviously, but if we have the 
data object, especially if it can only be used with one Document as in the 
current spec, I think it would be very confusing if exceptions were raised 
when things like elements were put into the data. It also seems like it 
wouldn't really gain us anything -- in the cross-session case (restarting 
the browser, etc) these data objects, according to the spec today, would 
be thrown out anyway.

If we want to handle the cross-Document case (i.e. if we want to never 
have entries disappear from the session history) then I think we are 
better off just getting rid of the data argument altogether and always 
using the URL field.

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

Received on Monday, 4 August 2008 22:11:56 UTC