[whatwg] nested hashchange events

[Jonas Sicking]

On Thu, Jul 16, 2009 at 5:30 PM, Ian Hickson<ian at hixie.ch> wrote:
> 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.

Sounds good, thanks!

/ Jonas