- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 15 Sep 2009 01:34:58 +0000 (UTC)
On Wed, 9 Sep 2009, Olli Pettay wrote: > On 6/25/09 11:44 AM, Olli Pettay wrote: > > > > 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. Fixed. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 14 September 2009 18:34:58 UTC