jonas at sicking.cc
Sun Jul 27 06:46:13 PDT 2008
Jonas Sicking wrote:
> To minimize the difference between when a SH entry is recovered from the
> fastback cache, compared to when the document is reparsed, the Location
> object should be changed to reflect the new URL whenever pushState is
> called with a url. The advantage of changing the Location object is that
> this makes the page behave the same no matter of if it has been reloaded
> or not. Setting the Location objects value will cause reloading vs.
> scrolling vs. do nothing in the same cases. Similarly reading the
> Location will return the same thing no matter of if there has been a
> reload or not.
> Yes, this is different from how legacy browsers behave. However the
> whole point of this API is to improve on the current iframe hacks. If we
> didn't there would be no point in adding a new API as it wouldn't be
> worth the code fork for users.
> Reloads mostly don't work with the iframe hack anyway so you'll end up
> with vastly different behavior no matter what. And if we're not
> considering the reload case then the hashchanged event should be enough.
> This isn't a big deal though as far as I can think of. Only if your
> application runs inside someone elses iframe and that outer app is
> intimately interacting with you I can see that it makes a difference.
> This doesn't seem common enough that we should prioritize for it.
Additionally, I just noticed that gmail does set the location.hash of
the top window. So gmail would want to change the Location object for
compat with legacy browsers.
And a library that used a hidden iframe for legacy browsers and really
wanted to be compatible as far as the Location object goes (though i'm
still unconvinced that anyone cares) could use iframe.history.pushState();
More information about the whatwg