[whatwg] nested hashchange events
Olli.Pettay at helsinki.fi
Thu Jun 25 09:31:31 PDT 2009
IE8 seems to fire hashchange asynchronously.
So it fires some time after window.location = "somenewvalue"; has been
Perhaps asynchronous firing is good enough (and it certainly is easier
to implement safely) and could be added to the spec.
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
>> 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.
More information about the whatwg