[css-view-transitions-1] Positioning of ::view-transition (the root pseudo)

[jakearchibald]

In #7859 we resolved on the concept of a "snapshot viewport", which would be consistent regardless of things like URL bar, virtual keyboard, and scrollbars, meaning animations would be stable, even if those things only existed on one side of the transition.

This means ::view-transition would fill this snapshot viewport throughout the transition.

We see two options to achieve this:

Option 1: Position ::view-transition per frame

::view-transition would use regular position: fixed positioning. inset: 0 would only fill the layout viewport, which is often smaller than the snaphshot viewport. So, to fix this, negative inset values would be used to make ::view-transition fill the snapshot viewport. These values would be updated per frame, to ensure the positioning is correct during any state changes (eg url bar hiding/showing).

This would be developer-visible via getComputedStyle, and would behave differently if the position was set to a non-fixed value.

In browsers that use a compositor to manage position: fixed items, there's a worry that there may be rendering instability in frames where the compositor is 'ahead' of the main thread's updates to the inset.

Option 2: Layout ::view-transition within the "snapshot viewport"

The ::view-transition would have position: fixed; inset: 0. However, we would use spec prose to say this pseudo is laid out in the snapshot viewport, so position: fixed; inset: 0 would cause ::view-transition to fill the snapshot viewport, rather than the layout viewport.

This wouldn't have the compositor issues, as it isn't dependent on main thread style updates. However, it's perhaps a bit weird for this one pseudo to appear to treat layout differently. Is there anything else that does something similar?

---

We're leaning towards "option 2".

[bokand]

Assuming we go with option 2, a related issue is what happens if author style does something else, e.g. position: absolute. Should that work and what does it mean? Is it possible to say author style cannot affect the position of this element? Or else, can we spec that this lives in its own formatting context with absolute & fixed containing blocks being the "snapshot viewport"?

[jakearchibald]

Or else, can we spec that this lives in its own formatting context with absolute & fixed containing blocks being the "snapshot viewport"?

That's my preference.

[khushalsagar]

+1 to author style can not change the computed position of ::view-transition.

[jakearchibald]

Isn't it better to just say the snapshot viewport is ::view-transition's containing block? Then, even if the position value is changed, it's still laid out in the snapshot viewport.

[khushalsagar]

Fair. So ::view-transition's containing block is the snapshot viewport which has no ancestor containing block. No matter what its position value is, the containing block remains the same.

[astearns]

Since this change has consensus here and will get wider review once we commit the change, we likely do not need to spend meeting time on it.

The CSSWG will automatically accept this resolution one week from now if no objections are raised here. Anyone can add an emoji to this comment to express support. If you do not support this resolution, please add a new comment.

Proposed Resolution: ::view-transition's containing block is the snapshot viewport

[astearns]

RESOLVED: ::view-transition's containing block is the snapshot viewport