[whatwg] nested 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.

So the synchronous hashchange causes this problem again;
per the draft the event is dispatched first and the scrolling happens 
after that.


-Olli

Received on Tuesday, 8 September 2009 14:08:18 UTC