Intent to Implement: <virtual-list> element layered API

155 views
Skip to first unread message

Domenic Denicola

unread,
May 2, 2018, 7:27:01 PM5/2/18
to blin...@chromium.org

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

unread,
May 9, 2018, 1:29:03 PM5/9/18
to blink-dev
looking forward to this feature!The performance of virtual list is a pain for web developer.

在 2018年5月3日星期四 UTC+8上午7:27:01,Domenic Denicola写道:
Reply all
Reply to author
Forward
0 new messages