

Chromium proposal for browser-level infinite scrolling lists: Lazy Block Layout - guybrush0
https://docs.google.com/a/chromium.org/document/d/1-tbcMJV8wNbX2g5ehNIcE_1W7Kj_B3g9w1BrUgHnh3U/edit

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

~~~
thezilch
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
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?

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

~~~
lmm
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?

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

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

------
jewel
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
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...](http://www.youtube.com/watch?feature=player_embedded&v=xuMWhto62Eo)

~~~
jewel
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
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
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
I can't imagine XML anything being pleasant to work with to be honest.

------
nevir
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
Things I'd like to see on browser native engine:

* markdown renderer

* jQuery core

* crypto

* gzip/deflate/xz/zip compression/decompression

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

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

