Intent to Implement: Searchable Invisible DOM

[Rakina Zata Amni]

Contact emails

rak...@chromium.org, yo...@chromium.org, dom...@chromium.org, taba...@chromium.org  

Explainer

Link to explainer.

This idea is very early-stage and has not yet settled down enough for a specification.

Summary

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, but we shouldn't need to do all the work of layout/paint/etc.

Motivation

An increasing amount of content on the web is becoming virtualized: that is, kept in memory in some non-DOM data structure, with only the visible portion converted into DOM nodes and inserted into the document. However, the non visible parts suffer because they aren’t working with some things like find-in-page, anchor navigation, etc.

Risks

Interoperability and Compatibility

This feature is very early stage and implementing it is intended to give us insight into these risks as developers experiment with it.

Edge: No signals

Firefox: No signals

Safari:  No signals

Web developers: No signals, but virtual content is a widely used concept. (https://m.twitter.com, React Virtualized)

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/5105291213406208

Requesting approval to ship?

No

[Rakina Zata Amni]

Update on this proposal:

The Searchable Invisible DOM proposal has merged with Display Locking, and all further development around this area will be under Display Locking, not Searchable Invisible DOM anymore. With display locking, developers can have some control on when to pay rendering costs, while also allowing user-agent features such as find-in-page, accessibility, indexability, focus navigation, anchor links, etc. to work with the display locked elements.