Open khushalsagar opened 3 weeks ago
cc @mattwoodrow
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
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.
If an element in the new Document for a cross-document transition has
content-visibility: auto
, it'sview-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 withcontent-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