[whatwg] nested hashchange events

On Thu, 25 Jun 2009, Olli Pettay wrote:
> 
> currently "6.11.9 History traversal" doesn't seem to handle
> nested hashchange events too well.

Oops. 'hashchange' is supposed to be asynchronous. My bad. Fixed.


> 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.

Yeah, the events should fire after the scrolling has occurred. This was an 
oversight. (It's supposed to work the same as 'popstate', which was 
already defined as asynchronous.)


> 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.

Agreed.


> 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.

The event is intended for applications that use the #fragid as a way of 
storing app state. The expectation is that such an app would not be ready 
to handle state changes until the 'load' event has fired, and that the 
'load' event would take into account whatever the #fragid is at that time.


On Thu, 25 Jun 2009, Olli Pettay wrote:
>
> And it seems like IE scrolls first and then dispatches hashchange 
> events.

Excellent.


On Thu, 25 Jun 2009, Olli Pettay wrote:
>
> IE8 seems to fire hashchange asynchronously. So it fires some time after 
> window.location = "somenewvalue"; has been called. Perhaps asynchronous 
> firing is good enough (and it certainly is easier to implement safely) 
> and could be added to the spec.

That was the intent, yes. The spec now does this.


Please let me know if there is anything else I can help with here.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 25 June 2009 18:19:01 UTC