[css-view-transitions-2] Elements with content-visibility in new Document

[khushalsagar]

If an element in the new Document for a cross-document transition has content-visibility: auto, it's view-transition-name is skipped. This is because the algorithm to look for names runs before the first rendering loop on the new Document. And the initial state of elements with content-visibility: auto is computed as a part of update the rendering here.

The simple fix would be to force the determination of this state if a Document has an incoming cross-document ViewTransition.

@vmpstr @argyleink @noamr @nt1m

[nt1m]

cc @mattwoodrow

[nt1m]

The simple fix would be to force the determination of this state if a Document has an incoming cross-document ViewTransition.

I guess it works, but seems a bit weird to have a one-off exception

[khushalsagar]

I guess it works, but seems a bit weird to have a one-off exception

Not exactly one-off. content-visibility is subtle this way. There's other cases like getComputedStyle which force computing style for an element outside the rendering loop. In this case we don't need to force computing style, since VT spec already says that elements which aren't relevant to the user can be ignored. But we need to know which elements are relevant to the user.

That said, happy to hear if you have any other suggestions.

Early on we considered running the capture the new state algorithm within update the rendering loop that would have avoided it. But we needed to give authors a script hook to set up web animations targeting pseudo-elements after this step. And more script hooks in the later stages of update the rendering become a pain to maintain. There's already a loop there which has to run resize observer and content visibility state tracking multiple times until it settles.

[emilio]

We could also assume content-visibility: auto elements are relevant for the purposes of view-transition names. We do that for find in page and scroll-into-view already, correct?

[noamr]

I think we should update the https://drafts.csswg.org/css-contain-2/#relevant-to-the-user view-transition condition to include elements with a view-transition-name when there is an inbound transition

[emilio]

That on its own doesn't work tho, right? (Because of the timing issue described above)

[noamr]

Looking at it again, I'm not sure this is correct.
In step 6 of update the rendering, we call reveal, which ends up calling activate view transition, which sets the boolean in step 5.

All of this happens before the content-visibility loop.

Or am I reading the problem wrong?

[khushalsagar]

All of this happens before the content-visibility loop.

That's what's causing this problem and why it particularly affects only new DOM capture. For old DOM capture, looking for names happens after this step.

We could also assume content-visibility: auto elements are relevant for the purposes of view-transition names. We do that for find in page and scroll-into-view already, correct?

The problem with this is that it makes content-visibility somewhat irrelevant as an optimization if you add VT to your page. One of its goals was to make FCP faster by avoiding style/layout of content which is far offscreen. If we force it to be relevant on the first frame then that gain is lost.

The issue where we resolved on this behaviour also concluded that there's no user benefit to forcing this content to be relevant. There's no use-case where far offscreen content needs to participate in the transition. We just don't know the position of these nodes until the first layout to determine whether they should be locked or not. That's why the ideal fix would be to make that determination before we look for names in the new DOM.

Tangential question, "scroll-into-view" reminded me of "scroll-to-text". I suppose it's like having "find-in-page" automatically run on page load where we're forcing nodes to become relevant. I'd still say there's a user benefit/need to do that here but not for VT.

[noamr]

All of this happens before the content-visibility loop.

That's what's causing this problem and why it particularly affects only new DOM capture. For old DOM capture, looking for names happens after this step.

Ah so the purpose of the current condition in css-contain is to keep elements relevant after the captures I guess?