This directory is an implementation of a CSS feature content-visibility.
Other than the places that rely on the name content-visibility as developer exposed features, the code uses display-locking naming:
When a content-visibility property is specified with a value that may require locking, a DisplayLockContext is created on the element‘s rare data. The state of the context is updated by the style adjuster in response to style changes. Additionally, the element’s containment is also adjusted in style adjuster in response to the actual state of the DisplayLockContext.
In lifecycle phases, such as style, layout, and paint, code checks LayoutObject::LayoutBlockedByDisplayLock and similar functions in order to determine whether processing of work should happen. The function takes a DisplayLockLifecycleTarget enum, with either kSelf or kChildren values in order to identify whether the element itself should layout.
Note that due to the evolution of the feature, kChildren is the typical value to use.
Note that the LayoutObject checks delegate the decision to the DisplayLockContext and can be thought of as helper functions.
The DisplayLockContext thus acts as an authoritative source of information when it comes to deciding whether contents lifecycle should be processed in response to content-visibility values. It is also responsible for blocking dirty-bit propagation and restoring the dirty-bit state upon unlocking.
In addition to DisplayLockContext and LayoutObject helper functions, a DisplayLockUtilities class is provided with a set of static functions that perform common functionality, such as checking whether an element is within a locked subtree without itself being locked.
This feature is new, and some work is continuing in the area.
In particular, we are working on adding a beforematch event as well as a hidden-matchable value for content-visibility property which allows searchability in hidden content.