W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2009

[whatwg] nested hashchange events

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 17 Jul 2009 00:30:10 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0907170016430.23663@hixie.dreamhostps.com>
On Fri, 26 Jun 2009, Jonas Sicking wrote:
> On Thu, Jun 25, 2009 at 6:19 PM, Ian Hickson<ian at hixie.ch> wrote:
> > On Thu, 25 Jun 2009, Olli Pettay wrote:
> >> 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.
> 
> But couldn't a page store state in the hash while the page is still 
> loading? At least in Firefox changing the hash while the page is loading 
> works just as well (with regards to activating back/forward, and with 
> regards to not reloading but rather just "scrolling") while the page is 
> still loading, as it does after the "load" event has fired.
> 
> A slow loading image file will delay the load event, however there's no 
> reason the scripts on the page wouldn't be able to deal with any user 
> interaction just as if the image had loaded.

So I looked into this, and it seems the reason for the way this is set up 
is for consistency with the popstate="" event, which is delayed until the 
load event fires, and the reason _that_ is delayed, is that we really 
don't want to miss any state objects being fired, and there's no way to 
know if it'll be missed if we don't have a well-defined event that fires 
before hand ('load', in this case).

However, I suppose there's no good reason to keep those consistent given 
that it means missing hash changes that you could detect by polling 
anyway, so I've removed the restriction for hashchange events.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 16 July 2009 17:30:10 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:14 UTC