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();
/ Jonas
