Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I've thought about this before - where you have a 2D array of images with infinite scroll in all directions.

You need to track the scroll position, and kill the elements that are scrolling away as you create the new elements in the direction you are scrolling - with the entire purpose of creating enough cached images so that it is seamless to the user.

The problem is that the scroll position changes back when you kill the old elements, so you need to keep a running tally of the matrix somewhere to track the user's position.



You could solve a lot of problems with position: absolute and javascript, which you assume is on.

A bigger problem is that mobile safari doesn't let you execute js during scroll. One way around that is by hsing iScroll which fakes scrolling using CSS.


That's right: a) you don't get scroll events until the scroll has finished, b) you do get touch events that drive the scroll (but nothing during the inertial part), c) the appearance of the page is not updated until the scroll has finished.

You can get around this by using programmatic scrolling (e.g., iScroll, zynga-scroller) but you'll never get quite as nice scrolling as with the native behaviour.


You can use the touchmove event to do things while mobile safari scrolls.



Looking back at the code that I was thinking of, it looks like I was using requestAnimationFrame to do the actual DOM manipulation (based on a variable that was updated in touchmove). Maybe Mobile Safari still allows DOM manipulation during those animation frame callbacks, even if touchmove is happening?


I suppose that’s the way most maps operate: loads map tiles and anchors current viewport properties in URL. Difference is that there is no 'real scroll position with real scrollbar'.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: