[whatwg] nested hashchange events

Olli Pettay Olli.Pettay at helsinki.fi
Thu Jun 25 01:44:11 PDT 2009


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



More information about the whatwg mailing list