[whatwg] nested hashchange events
ian at hixie.ch
Mon Sep 14 18:34:58 PDT 2009
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.
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg