[whatwg] nested hashchange events

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.

/ Jonas

Received on Friday, 26 June 2009 00:59:32 UTC