Intent to Implement: Searchable Invisible DOM

Skip to first unread message

Rakina Zata Amni

Aug 13, 2018, 5:20:30 AM8/13/18
to blink-dev,,,

Contact emails,,,  


Link to explainer.

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


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.


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.


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. (, React Virtualized)

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?


Rakina Zata Amni

Apr 3, 2019, 9:58:51 PM4/3/19
to blink-dev, Domenic Denicola, Tab Atkins, Yoshifumi Inoue
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.
Reply all
Reply to author
0 new messages