Chromium proposal for browser-level infinite scrolling lists: Lazy Block Layout | Hacker News Reader

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

docs.google.com

69 pointsguybrush028 comments

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

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/

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

Check out deviantArt's infinite scroll implementation. If you go to their home page, and scroll to the bottom, there's a big green "Show More" button. No infinite scrolling happens until you explicitly want it to and you are able to get to the stuff in the footer. Once you start scrolling, it's very fast and there's not much of a delay as it loads more things. It also updates the URL as you scroll so when you click on something and hit the back button you are where you left off. It's quite slick.

The Tumblr "dashboard" (feed) is pretty good. Also, collections and news on Are.na.

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?

No, because FB puts the same links and content under the right-hand side. Can you enumerate the issues that need to be addressed? I have ready of research on the lack-luster implementations (eg. Twitter) that many assume is the status quo.

My biggest problem is how to get back to where I was. I was reading a funny tumblr on my phone and got to the point where the page was incredibly slow, so I wanted to start reading again from where I currently was in the page... how do I do that?

The great-grandparent of your reply details such a solution.

Oh, boy. It drives me absolutely insane when I try to click on a footer link, scroll down, and just before I click, another batch of the infinite list shows up and pushes the footer further away. Kickstarter is guilty of this, among many others.

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.

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.

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...

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.

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

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.

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.

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...

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.

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.

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

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

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.

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

* markdown renderer

* jQuery core

* crypto

* gzip/deflate/xz/zip compression/decompression

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

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

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.)

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()).

Reply on news.ycombinator.com