[whatwg] nested hashchange events

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 03:46:19 UTC