We currently can’t scroll on the body element due to a limitation in Chrome, where an empty body layer is not being optimized. So we are scrolling in an element. However, that usually requires setting `-webkit-overflow-scrolling: touch;` so that you can scroll as usual on iOS. However, that in turn has a lot of hidden implications (like squashing layers, etc. Don’t know the details right now), that make performance suffer greatly.
AFAIK, Safari will change their scroll-on-element behavior. Let’s see what the future brings.
Lots of good points here! This article (and the implementation) were born out of the frustration with the lacking performance of most infinite scrollers. We were aware of some of the issues you list (I’m not going to claim we thought of everything ;) ), which is also the reason why we are not providing a library for people to use. Too much left to do right.
> Navigation controls
Definitely something that needs thinking and that we intentionally didn’t address here.
> Ctrl+F
We were think on how to solve this, but we weren’t able to come up with anything using the tools the platform provides currently. Maybe a future API will help here.
> Scrollbars
I thought we did a pretty good job on the scrollbar. You can still click the scrollbar indicator and drag it around to quickly jump from position to the other. It’s not AS accurate, but still useful and doesn’t diminish UX imo.
> Jumping scrollbar
Should barely happen! We are using a sentinel element to define the length of the runway, not the elements themselves to minimize jumping. I think it can only happen if elements grow drastically in height when going from tombstone to actual content.
> “Adaptive DOM pool”
This is definitely an improvement that could be made. Currently we just maintain N elements and N tombstones in memory. N could dynamically adapt to the capabilities of the device.
> Caching
How much caching is utilized is very much up to you. If the API doesn’t provide good caching headers you could implement that yourself in the data source. I think this falls outside of the technical scope of the scroller itself.
Yes, your solution is correct! I discovered this issue too late for launch, but I have a PR open with this.
It needs some extensive testing because there might be weird interactions with our layout component and all the different header modes it has (scrolling header, waterfall, etc). Working on it :)
I agree. I thought it would be a blank project skeleton you are supposed to clone, but it’s not. So `go get` would make much more sense on the landing page.
I totally feel you, and that is what Houdini’s Custom Layout is going to be about: https://github.com/w3c/css-houdini-drafts/blob/2b730220b2f3c...
I want to write a blog post about constraing based layouts on the web specifically, but the TL;DR on why we don’t have it already:
Standardization is hard. It’s especially hard to reach consensus when:
* the runtime for a layout algorithm is hard to estimate
* it can _fail_ (which is unprecedented in CSS)
* a new syntax for constrains would have to be defined.