Re: [whatwg] nested hashchange events
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. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] nested hashchange events
On 6/25/09 11:44 AM, Olli Pettay wrote: Hi all, 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. -Olli
Re: [whatwg] nested hashchange events
On Fri, 26 Jun 2009, Jonas Sicking wrote:
On Thu, Jun 25, 2009 at 6:19 PM, Ian Hicksoni...@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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] nested hashchange events
On Thu, Jul 16, 2009 at 5:30 PM, Ian Hicksoni...@hixie.ch wrote:
On Fri, 26 Jun 2009, Jonas Sicking wrote:
On Thu, Jun 25, 2009 at 6:19 PM, Ian Hicksoni...@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
Re: [whatwg] nested hashchange events
On Thu, Jun 25, 2009 at 6:19 PM, Ian Hicksoni...@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
Re: [whatwg] nested hashchange events
And it seems like IE scrolls first and then dispatches hashchange events. On 6/25/09 11:44 AM, Olli Pettay wrote: Hi all, 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. 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. -Olli
Re: [whatwg] nested hashchange events
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. -Olli On 6/25/09 1:46 PM, Olli Pettay wrote: And it seems like IE scrolls first and then dispatches hashchange events. On 6/25/09 11:44 AM, Olli Pettay wrote: Hi all, 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. 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. -Olli
Re: [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. `._.-(,_..'--(,_..'`-.;.'
