This idea is very early-stage and has not yet settled down enough for a specification.
Similarly, we are delaying TAG review for now. When we are more sure that the API won't change drastically and invalidate all feedback, we will submit a TAG review request.
The design and API surface of virtual-list is very tentative. We will be exploring many different choices behind a flag to see what makes the most sense, before we work on standardization and eventually shipping.
Virtual lists have become a very common pattern with high developer demand. They are difficult to implement well and evaluating a given implementation is particularly hard.
In addition, we believe that virtual lists have the potential to address a large class of rendering performance problems that web authors regularly encounter around having too much DOM. This is a problem that native mobile platforms mostly don’t hit largely because the natural way to build apps on those platforms involve virtual lists.
Interoperability and Compatibility
This feature is early stage and implementing it is intended to give us insight into these risks as developers experiment with it.
In particular, we are going to be spending a lot of time figuring out what aspects of observable behavior a virtual-list implementation exposes, and how to specify those. Since the internals of this element will be more visible than those of other UI controls (such as <select> or <video controls>), care will be needed here.
Edge/Firefox/Safari: No public signals.
Web developers: No public signals. Some private discussions have indicated interest, but a large part of the reason we're prototyping this is to give folks something to work with to see if it would be usable in production.
We anticipate usage of this element making it much easier for Chrome to maintain good rendering performance, by reducing the amount of elements in the DOM.
Due to building on the layered APIs infrastructure, it will be relatively easy to polyfill. It uses no magic capabilities inaccessible to web devs today. And in the future when other browser support the layered API infrastructure, fallback to a polyfill will be easy using the built-in layered API fallback support. In the meantime, developers can use the layered API feature detection pattern and load their polyfills that way.
Because virtual-list is layered on top of custom elements and shadow DOM, it is inspectable in the usual way via DevTools.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Link to entry on the feature dashboard
Requesting approval to ship?