content-visibility: auto allows the user agent to minimize the rendering cost for elements which are not relevant to the user. There are multiple subtle interactions this optimization has with View transitions.

1. Identifying elements with a valid page-transition-tag (and other constraints) requires all elements to have up to date style (see logic here). Offscreen elements can also participate in a transition since the transition might bring them onscreen. So content-visibility: auto shouldn't prevent discovery of a tagged element.

   The default behaviour would be for the transition to force style update for the whole DOM tree to discover tagged elements. We can add an option going forward (new contain keyword?) for the author to indicate that a sub-tree doesn't have tagged elements.

2. If an element with content-visibility: auto is tagged, it becomes relevant to the user.

3. If an element with content-visibility: auto has a descendant which is tagged, the element becomes relevant to the user. This is because we need to layout/paint the tagged element to render it in its corresponding replaced pseudo-element.

4. If an element with content-visibility: auto has an ancestor which is tagged then we have 2 cases:

   • If that ancestor is the root element then content-visibilty: auto can continue to apply. This is because the root snapshot is clipped to the viewport. See [css-shared-element-transitions-1] Define transitions over changing viewport #7859 for details.
   • If that ancestor is a non-root element then the content-visibility: auto node becomes relevant to the user. This is because snapshots for non-root elements are painted in their entirety (modulo hardware constraints).

@vmpstr to validate the summary.