One of the things i've recently built has an infinite scrolly feed of items, and http://airbnb.github.com/infinity/ is what I ended up using after using Masonry for a long time.
The example page (Tindie) is slow and chunky-scrolling on latest Firefox with my machine (16 gigs of RAM and quad Xeon)... It eats CPU. Something wrong with it. Doesn't happen in Chrome.
Maybe add some sort of visual hint on Tindie to show that new content is being loaded. It takes sometime to load the new chunk and someone might think there's nothing more to see down there.
You're right. We had a staggered layout, a la Pinterest, until last week. Now that we've evened up everything, I'm sure we could remove Masonry. It's currently still using it, though.
Oh nice, the best takeaway from this (for me) was that desandro apparently has created a hack to deal with the whole is-an-image-in-cache-or-isn't-it problem:
The best way to avoid this altogether is to set the image width and height in the img tag. That way, content can be shown right away, even before the images are loaded.
Another thing to be careful with are social buttons, whose height may change after the initial item is rendered. That's easily avoided with a fixed CSS height, though.
It depends on the backend workflow, no? If your system pulls in images and does the resizing, including the determination of horizontal vs. vertical, then outputting defined css selectors is straightforward.
However, if you're only in control of the front-end and are just reading from an API of photos where you're given a stream of image urls...how do you determine which css-selector (i.e. '.vert-image' and 'horz-image' with defined h/w dimensions) to put out? You can obviously just restrict everything to a one-size box, but either the vertical or the horizontal images are going to be given short shrift.
Edit: along with Scroll Events http://james.padolsey.com/demos/scrollevents/