IE8 seems to fire hashchange asynchronously.
So it fires some time after window.location = "somenewvalue"; has been
called.
Perhaps asynchronous firing is good enough (and it certainly is easier
to implement safely) and could be added to the spec.
-Olli
On 6/25/09 1:46 PM, Olli Pettay wrote:
And it seems like IE scrolls first and then dispatches hashchange events.
On 6/25/09 11:44 AM, Olli Pettay wrote:
Hi all,
currently "6.11.9 History traversal" doesn't seem to handle
nested hashchange events too well.
If there is a fragment id change to A, hashchange is dispatched, then
if the listener changes the fragment to B, there is a new hashchange and
after that the page will scroll to B. But the fragment change to A
hasn't finished yet, so the page will then scroll to A.
Either one should be able prevent the default action of hashchange
(scrolling), or hashchange should be dispatched after scrolling.
I think I'd prefer the latter. That would keep things simple and prevent
all sort of strange cases like the example above if preventDefault isn't
called.
Also, what is the reason for "if the Document's current document
readiness is the string 'complete'" requirement?
I often click fragment links while the page is still loading, especially
when the page is large or slow loading. Why shouldn't the
page get notified that it has scrolled to some new location because of
fragment id change.
-Olli
