[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