Browsers are beginning to form a standard around browser-native virtual scrolling.
[GitHub - WICG/virtual-scroller]
A built-in virtual scroller for the web platform
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]
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]
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]
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.
