ian at hixie.ch
Mon Aug 4 22:11:56 PDT 2008
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
> * 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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg