Chromium proposal for browser-level infinite scrolling lists: Lazy Block Layout

Chromium proposal for browser-level infinite scrolling lists: Lazy Block Layout(docs.google.com)

69 points by guybrush0 13 years ago | 28 comments

fletchowns 13 years ago |

I can't be the only one that absolutely despises infinitely scrolling lists, right?

mattchew 13 years ago | |

Nope. Give me one long page or page links. I hate the perpetual pausing, I hate being unable to go directly to the end of what I'm reading. I like to feel in control over what I'm looking at, and infinite scroll ain't that.

I hope it is a fad that passes.

thezilch 13 years ago | |

Depends, infinite scrolling can be and has been done right [0], but it's really not the focus of the feature -- it's a product.

[0] http://warpspire.com/experiments/history-api/

just2n 13 years ago | | |

Having a linkable infinite scroll is only solving one of the issues in infinite scroll.

Have you ever tried to click the links in Facebook below your news feed?

Why is it that everyone who implements automatic infinite scroll shoves it into a context where there's stuff beneath it on the page, making that content completely inaccessible?

fletchowns 13 years ago | | |

Maybe I just haven't seen it done right - do you have some example links?

masklinn 13 years ago | |

Well done ones (e.g. in native iOS applications) work really well in my experience, they're regular lists with memory savings.

Badly implemented ones (which is 97% of those on web sites) on the other hand...

dombili 13 years ago | |

I don't hate it, but some websites implement it so badly. Sometimes I want to reach the career or about page of a website, but it's hard to do that when the page is constantly scrolling. I usually end up typing /about at the end of the URL.

zimbatm 13 years ago | |

It depends if all the content needs to be consumed or not. Twitter/Facebook where I realistically won't read every entry it's fine. In some ways the list can be considered infinite.

All other cases of finite lists shouldn't use infinite scrolling. It breaks jumping back to a specific position and the length is not predictable.

mbesto 13 years ago | |

http://danwin.com/2013/01/infinite-scroll-fail-etsy/

jimrandomh 13 years ago |

I encountered a similar issue awhile back with a Chrome-based terminal emulator, which this would also solve. Every time it outputs a line, it scrolls to the bottom, which forces a reflow; and if the scrollback is long, the reflows get slow, and performance ended up being really pathetic. The solution ended up being a hack to prevent the per-line reflows (Javascript scrolling and bottom-relative positioning), but this would be a better fix.

jewel 13 years ago |

I've been working on a problem that this browser extension would solve really well. I've got a photo gallery with a hundred thousand photos in it where I implemented near-infinite scroll by creating a really tall div and then drawing about 2x as many thumbnails as are needed to fit in the current viewport, which is updated when the user scrolls. They are square thumbnails so it is easy to calculate exactly where to position each of them.

The advantage of this over infinite scroll is that the scrollbar is always there and always accurate, so coming back to the page after following a link works properly. Also, I don't have to send the information about all 100k photos on page load (I can load it with AJAX).

A demo of how it works is at http://beta.hypercheese.com/search, and the code is at http://github.com/jewel/hypercheese/.

It sounds like having this in the browser will allow for much more complex layouts.

enra 13 years ago | |

Cool, but seems like with your implementation, you can scroll too fast and get lost in the "white". Not sure how fix it, possible showing somekind of grid before loading the images could help.

There is a good talk from Netflix team about the problem, specially with low-performance machines. They slowed scrolling so you couldn't get lost. http://www.youtube.com/watch?feature=player_embedded&v=x...

jewel 13 years ago | | |

Thanks for the feedback. Rendering a grid would be easy to do and would help a lot.

I am debouncing the scroll events right now and haven't tried making the timing more aggressive so that it doesn't sit at white for as long as it does. Right now the long pause is just because of a timer.

bicknergseng 13 years ago |

I can't tell if this would help rendering large lists of dom elements that are loaded all at once... eg what things like infinity.js, ember tables, etc do. I wish there was a UITableView for the web that was more native than any of those solutions.

shardling 13 years ago | |

Mozilla's XUL had a native treeview element, and I remember it being horrible to work with.

https://developer.mozilla.org/en-US/docs/XUL/tree

bicknergseng 13 years ago | | |

I can't imagine XML anything being pleasant to work with to be honest.

nevir 13 years ago |

The web (and WebKit in particular) is on track to catch up w/ native frameworks in terms of tools at the disposal of developers. Albeit in a slightly more rough form.

The next 5-10 years are going to be interesting.

est 13 years ago |

Things I'd like to see on browser native engine:

* markdown renderer

* jQuery core

* crypto

* gzip/deflate/xz/zip compression/decompression

pspeter3 13 years ago | |

I agree with crypto and gzip but you'll have versioning problems with jQuery core and some people like having custom markdown syntax

AskHugo 13 years ago | |

Instead of implementing the whole of jQuery core, they could just add some of the features. It seems like that's already being done though (e.g. Element.querySelector()).

bcoates 13 years ago | |

What do you need compression for that you can't just use content-encoding?

kevingadd 13 years ago | | |

Think about the places where the average application uses compression codecs.

Now, think about the kinds of applications people are trying to build in web browsers.

If you were to represent these two groups as a venn diagram, you would have one giant honkin' circle.

(A few examples for the lazy: On-the-fly content compression/decompression for games; caching large amounts of application data in compressed form in order to reduce disk space usage; using compression codecs that are faster or produce better compression ratios than gzip.)