Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

docs.google.com

Post reply on HN
Print view View original

11–20 of 30 posts

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

#11

Post by just2n »

thezilch wrote: post #7
fletchowns wrote: post #6

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/

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?

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

#12

Post by thezilch »

just2n wrote: post #11
thezilch wrote: post #7

Earlier quoted context omitted.

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/

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.

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

#13

Post by enra »

jewel wrote: post #9

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 p…

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

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

#14

Post by mattchew »

fletchowns wrote: post #6

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

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.

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

#15

Post by bicknergseng »

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.

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

#16

Post by rubinelli »

just2n wrote: post #11
thezilch wrote: post #7

Earlier quoted context omitted.

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/

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?

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.

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

#17

Post by jewel »

enra wrote: post #13
jewel wrote: post #9

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 p…

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.

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

#18

Post by shardling »

bicknergseng wrote: post #15

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

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

#19

Post by jimrandomh »

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.

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

#20

Post by kevingadd »

bcoates wrote: post #4
est wrote: post #2

Things I'd like to see on browser native engine: * markdown renderer * jQuery core * crypto * gzip/deflate/xz/zip compression/decompression

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

Post reply on HN