So, err... I think I've got it mostly right, this time...!
I did a test on the New Revs topic, which is just a lot of text, and it loaded the first 10 pages pretty much instantly. After 10 pages, though, it started getting a bit slower.
After 32 pages loaded, the page was really slow to load. At least, it wasn't slow to process, but it finished internal execution *after* I'd reached the bottom, and since the event is now only called on 'scroll', I can't just scroll down to show the page, since the event doesn't trigger at all. I could alternatively 'install' a temporary mouse wheel event when the end of the page is reached, and remove it later, but that sounds a bit awkward, I don't know... The point of the 'scroll' event is that you can still trigger the page prefetch by simply hitting the 'Page End' key on your keyboard, but then you have to use Up and Down arrows once to actually show the content.
Still, I don't like the idea of automatically showing available content as it becomes ready, because I want people to still be able to easily access the footer, and most importantly, the page index list (of course, they can do it by going to the top of the page, but it's rather inconvenient.)
Basically, we're in user experience land, here, and I'm not what I can, but... I guess I need *user* feedback, eh... ;)
I think the method I used in rev 2268 is pretty fine for 10 pages, but beyond that, I should instead specifically target the new posts, e.g. with a div ID as context.
I'm not sure it's for the best, though... I mean, 10 pages is a lot to read through, and beyond that, you may get lost. I'm thinking, *maybe* I could forcibly stop the infinite scrolling process after 10 pages, and invite the user to just press the Next link, and then they'll be free to start another session of 10 pages. I don't know, what do you think..? Or is it better to give absolute freedom, like now?
I did a test on the New Revs topic, which is just a lot of text, and it loaded the first 10 pages pretty much instantly. After 10 pages, though, it started getting a bit slower.
After 32 pages loaded, the page was really slow to load. At least, it wasn't slow to process, but it finished internal execution *after* I'd reached the bottom, and since the event is now only called on 'scroll', I can't just scroll down to show the page, since the event doesn't trigger at all. I could alternatively 'install' a temporary mouse wheel event when the end of the page is reached, and remove it later, but that sounds a bit awkward, I don't know... The point of the 'scroll' event is that you can still trigger the page prefetch by simply hitting the 'Page End' key on your keyboard, but then you have to use Up and Down arrows once to actually show the content.
Still, I don't like the idea of automatically showing available content as it becomes ready, because I want people to still be able to easily access the footer, and most importantly, the page index list (of course, they can do it by going to the top of the page, but it's rather inconvenient.)
Basically, we're in user experience land, here, and I'm not what I can, but... I guess I need *user* feedback, eh... ;)
I think the method I used in rev 2268 is pretty fine for 10 pages, but beyond that, I should instead specifically target the new posts, e.g. with a div ID as context.
I'm not sure it's for the best, though... I mean, 10 pages is a lot to read through, and beyond that, you may get lost. I'm thinking, *maybe* I could forcibly stop the infinite scrolling process after 10 pages, and invite the user to just press the Next link, and then they'll be free to start another session of 10 pages. I don't know, what do you think..? Or is it better to give absolute freedom, like now?
