[whatwg] pushState

[Jonas Sicking]

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