[whatwg] nested hashchange events

[Olli Pettay]

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
>>
>
>