Intent to Implement: <virtual-list> element layered API
Domenic Denicola
Contact emails
dom...@chromium.org, val...@chromium.org, hiro...@chromium.org
Explainer
https://github.com/valdrinkoshi/virtual-list/blob/master/README.md
Design doc/Spec
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.
Summary
<virtual-list> maps a provided set of JavaScript objects onto DOM nodes, and renders only the DOM nodes that are currently visible, leaving the rest "virtualized". It will be implemented as a layered API, on top of many existing technologies: custom elements, shadow DOM, IntersectionObserver, ResizeObserver, etc.
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.
Motivation
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.
Risks
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.
Ergonomics
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.
Activation
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.
Debuggability
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)?
Yes.
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/5673195159945216
Requesting approval to ship?
No.
Eric Lee
在 2018年5月3日星期四 UTC+8上午7:27:01，Domenic Denicola写道：