# Native browser virtual scroller
**URL:** https://meta.discourse.org/t/native-browser-virtual-scroller/116143
**Category:** Development
**Created:** [April 27, 2019, 10:06pm UTC](https://meta.discourse.org/t/native-browser-virtual-scroller/116143 "2019-04-27T22:06:17Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@dfabulich](https://meta.discourse.org/u/dfabulich)
#### Post date: [April 27, 2019, 10:06pm UTC](https://meta.discourse.org/t/native-browser-virtual-scroller/116143/1 "2019-04-27T22:06:18Z")
Browsers are beginning to form a standard around browser-native virtual scrolling.
[[GitHub - WICG/virtual-scroller · GitHub](https://github.com/WICG/virtual-scroller)]
> A built-in virtual scroller for the web platform
[ ](https://www.youtube.com/watch?v=UtD41bn6kJ0)
They’re also exploring some really interesting low-level browser APIs that would allow find-in-page and a11y navigation for large volumes of invisible content.
[[GitHub - rakina/find-in-page-api · GitHub](https://github.com/rakina/find-in-page-api)]
> There have been a lot of interest in improving the find-in-page experience from web developers, including:
>
> - Giving the user a completely custom UI, suppressing the browser’s find UI, consistently
> - Allowing data not in the DOM tree to be findable, even if there might be an infinite amount of data
> - Reflecting real-time data loading/modification on find results
> - Treating multiple webpages as one searchable instance, e.g. books, multi-page articles, or the multipage HTML spec
[[GitHub - rakina/searchable-invisible-dom · GitHub](https://github.com/rakina/searchable-invisible-dom)]
> The proposal is to create some new way of exposing DOM to the browser, that is still _searchable_, but is _invisible_. That is, find in page must be able to search within this DOM and fragment navigation should be able to find a named invisible DOM, etc., but we shouldn’t need to do all the work of layout/paint/etc.
[[GitHub - WICG/display-locking: A repository for the Display Locking spec · GitHub](https://github.com/WICG/display-locking)]
> This document proposes to augment user-agent APIs to help address the problem of **slow rendering phase updates** , and having some control on **when to pay rendering costs**. Specifically, we propose a concept of _display locking_ an element.
>
> If an element is display locked, it means that **any DOM, style or layout updates to its subtree are not rendered immediately**. Instead, when allowed, the user agent will process rendering updates _co-operatively_, yielding periodically to allow script or user interactions to happen. The web author can also commit the lock, which triggers a synchronous update and render when necessary, causing the element to get updated and rendered in the next frame.
>
> The web author can also opt-in to allow display-locked elements to be **committed by the user agent in cases like focus navigation, find-in-page match navigation** , etc. so that they are properly rendered when needed in those cases.
Stuff like this seems highly relevant to the implementation of Discourse.
---
### Author:  [@dfabulich](https://meta.discourse.org/u/dfabulich)
#### Post date: [April 29, 2019, 6:07pm UTC](https://meta.discourse.org/t/native-browser-virtual-scroller/116143/2 "2019-04-29T18:07:40Z")
FYI, it’s looking like Google’s Plan A approach to this is falling apart. Mozilla and Apple have come out against the Display Locking API. [content-visibility API · Issue #135 · mozilla/standards-positions · GitHub](https://github.com/mozilla/standards-positions/issues/135)
It might be wise to start participating in this conversation sooner than later. My understanding is that Chrome has a working prototype implementation behind a flag. It might be worth building out a prototype to see what y’all like and don’t like about it.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [April 30, 2019, 8:41am UTC](https://meta.discourse.org/t/native-browser-virtual-scroller/116143/3 "2019-04-30T08:41:22Z")
There’s no way we’d have the bandwidth to get involved in this.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [March 20, 2021, 12:20am UTC](https://meta.discourse.org/t/native-browser-virtual-scroller/116143/4 "2021-03-20T00:20:08Z")
Did this go anyhere @dfabulich ?
---
### Author:  [@dfabulich](https://meta.discourse.org/u/dfabulich)
#### Post date: [March 20, 2021, 12:37am UTC](https://meta.discourse.org/t/native-browser-virtual-scroller/116143/5 "2021-03-20T00:37:37Z")
Yes! The browser standard evolved to become the `content-visibility` property. It shipped in Chrome 85, and therefore also available in Edge and Opera. [https://caniuse.com/?search=content-visibility](https://caniuse.com/?search=content-visibility)
Watch this video… it’s freakin’ amazing.
[ ](https://www.youtube.com/watch?v=FFA-v-CIxJQ)
Here’s an in-depth article about it.
> **[content-visibility: the new CSS property that boosts your rendering...](https://web.dev/articles/content-visibility)**
>
> The CSS content-visibility property enables web content rendering performance benefits by skipping rendering of off-screen content. This article shows you how to use this new CSS property for faster initial load times, using the auto keyword. You...