- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Thu, 25 Jun 2009 19:31:31 +0300
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 >> > >
Received on Thursday, 25 June 2009 09:31:31 UTC