- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Thu, 25 Jun 2009 11:44:11 +0300
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 01:44:11 UTC