[css-view-transitions-2] Optionally capture some properties (e.g. opacity/border) as style instead of snapshot

[noamr]

The current way we capture view-transition participating elements is tuned to a flat tree of crossfade+transform animations: we save the element's relevant properties (transform from root, mix-blend-mode, color-scheme) and everything else is baked into the snapshot.

However, #10334 (nested transition groups) makes it so that this pattern might need to be expanded: to display clipping and tree effects in an expected manner, those would have to be copied into the group rather than baked into the snapshot.

The following (non-exhaustive?) list of CSS features would have a different behavior in a nested transition tree:

• tree effects (opacity, filter, image-mask)
• clipping (clip-path, overflow, border-radius)
• 3D (actual transform, preserve-3d, perspective, transform-origin)

The "odd" one out of these is border-radius together with overflow: since it has a unique effect of clipping its descendant but not clipping the border.

To render a rounded-corner element with nested clipped descendants correctly in terms of paint-order, the entire set of box decorations (backgrounds & borders) would have to be captured and applied to the group.

Also as per the resolution in #8282, we sometimes capture geometry only (when the old element is out of the viewport).

• TBD whether this needs its own bespoke thing or fits in with the capture modes concept.

So at the very least there could be 4 capture modes (each one includes the ones above it):

• geometry
• flat (geometry + snapshot + blend)
• composite (clipping + 3D + tree effects)
• layered (borders + background + shadow)
  (names bikesheddable to the bone)

Superficially, it would seem like this can be done automatically:

• Use geometry when out of viewport
• Use flat when in viewport
• Use composite when has nested descendants
• Use layered when has nested descendants and clipping border-radius

However, the issue with these capture modes is that by default they're incompatible with each other - so if we used one capture mode in the old state and one in the new state, the animation and the captured image would be out of sync, creating a buggy-looking animation like this: https://codepen.io/noamr-the-selector/pen/OJeymbe.

One path forward is to enable the author to define the capture mode (based on the above proposal or some other subdivision we decide on), and encourage authors to use this when using nested transitions, but not choose a capture mode automatically (except for geometry when out of screen).

[noamr]

A syntax alternative can be view-transition-style: motion || crossfade || composite || decoration || default where default means "motion when out of viewport, motion+crossfade when in-viewport"

[noamr]

Notes from internal conversation: for starts, having two modes is enough:

• The current mode, where elements are captured for a crossfade
• The "max" mode: capturing the borders/background/clip/effects/3d as style and morphing them individually rather than as part of the image

Perhaps view-transition-style: crossfade | morph ?

To discuss/resolve:

• Should this be configurable separately per-element or once for the whole view-transition? The former feels more flexible perhaps?
• What do we do in case of mismatch?

[noamr]

Copying from #9406 for the purpose of the CSSWG breakout.

There are 3 use-cases that can benefit from changing the way we capture in certain scenarios:

1. Groups that have nested descendant with view-transition-group: they need to capture opacity, filters, 3D, and sometimes borders, backgrounds & shadows in order to display in a way that doesn't look buggy.
2. Sometimes, regardless of nesting, animating border and box-shadow can have a nicer effect than flattening them into the snapshot.
3. When an element comes from far away from the viewport, or if we're moving elements around without changing their content, we could benefit from an optimization of not capturing the old content into a snapshot at all.

I see this as 3 styles of transition, with an auto that generates default behavior:

• Crossfade between the old and new element snapshots, like today (crossfade?)
• Crossfade the contents and animate the box decorations individually (morph?)
• Display the new content only and morph only the box decorations (transpose?)

auto could mean:

• Use morph when the group contains other groups
• Use transpose when animating from very far from the viewport (100vw, 100vh?)
• Otherwise, use crossfade

[Psychpsyo]

auto could mean:

* Use `morph` when the group contains other groups

* Use `shapeshift` when animating from very far from the viewport (100vw, 100vh?)

* Otherwise, use `crossfade`

Is there a reason for auto not using morph automatically if two elements with differing 3D transforms (or similar) are being transitioned between?
Because like this, transitioning one 3D transformed element to a differently 3D transformed element just crossfades between the two and it looks rather janky.

[noamr]

auto could mean:

* Use `morph` when the group contains other groups

* Use `shapeshift` when animating from very far from the viewport (100vw, 100vh?)

* Otherwise, use `crossfade`

Is there a reason for auto not using morph automatically if two elements with differing 3D transforms (or similar) are being transitioned between? Because like this, transitioning one 3D transformed element to a differently 3D transformed element just crossfades between the two and it looks rather janky.

If an element is flat (doesn't have nested descendants), there shouldn't be a difference regarding the internal 3D transform (e.g. perspective), as the image is flattened anyway. The external transform is part of transitioning the geometry in all the styles.

[bramus]

(Got my bikeshedding hat on …)

Perhaps view-transition-style: crossfade | morph ?

The conversation here uses “capture mode“ as a term a lot, so maybe view-transition-capture-mode seems better?

• Crossfade between the old and new element snapshots, like today (crossfade?)

crossfade as a value feels weird here because authors can override the animation to something entirely different. IUC this is the current behavior where you get a flattened surface, so maybe flat as a value is better here?

• Crossfade the contents and animate the box decorations individually (morph?)

layered, maybe?

• Display the new content only and morph only the box decorations (transpose?)

This can already be controlled by authors, no?

::view-transition-old(x) { display: none; }
::view-transition-new(x) { animation-name: none; }

Most likely I’m missing something here … 🤔

---

All combined, I’m leaning to a view-transition-capture-mode: flat | layered | auto syntax.

[noamr]

(Got my bikeshedding hat on …)

Perhaps view-transition-style: crossfade | morph ?

The conversation here uses “capture mode“ as a term a lot, so maybe view-transition-capture-mode seems better?

• Crossfade between the old and new element snapshots, like today (crossfade?)

crossfade as a value feels weird here because authors can override the animation to something entirely different. IUC this is the current behavior where you get a flattened surface, so maybe flat as a value is better here?

Yea, it's whether this property implies "what default transition would this generate" whether "what does it capture".
I thought that referring to the default transition style is more design-oriented and referring to the capture is more technical, but perhaps more precise. This is definitely arguable!

• Display the new content only and morph only the box decorations (transpose?)

This can already be controlled by authors, no?

::view-transition-old(x) { display: none; }
::view-transition-new(x) { animation-name: none; }

Yea, but doing this in advance is an optimization, see #9406. We can also decide to not fold this optimization in the solution for this issue.

[noamr]

Summary from internal sync, we concluded that we'd defer the no-content-change to later.
There are 3 options on the table:

1. Change the capture mode by default. Capture box-decorations and tree effects as style, and cross-fade only the contents. This asserts that morphing rather than cross-fading is mostly superior. However, it might make some of today's view transition animate differently, e.g. a different background image between the old and new state would animate discretely.
2. Make this an opt-in with a new property (view-transition-style or view-transition-capture-mode), one option is like today, and the other one captures box-decorations & tree effects as style.
3. Add a new property, but give it an auto value. The capture-mode will be the same as today, unless the element is a containing group (has nested group descendants). This asserts that flat capturing doesn't make sense at all for a nested group tree, and it allows us to change that without breaking existing content.

Note that there are current cases where cross-fading the whole image would be smoother than animating the backgrounds or clip-paths, see #10759 and #10760. However, this is also achievable by adding a container element, where the external container would have the view-transition-name, and the internal container would have the backgrounds etc.

[css-meeting-bot]

The CSS Working Group just discussed [css-view-transitions-2] Optionally capture some properties (e.g. opacity/border) as style instead of snapshot, and agreed to the following:

• RESOLVED: Change the capture mode for all view-transitions and specify how each property is affected by this capture mode change
• RESOLVED: Blink will experiment and come back with changes needed if there are compat concerns
• RESOLVED: eventually describe categorization of properties in the Module Interactions sections of each spec

The full IRC log of that discussion

<bramus> noamr: biggest issue we want to discuss today
<bramus> … how we capture and display nested componets
<bramus> … but also applies to non-nested vt elements
<bramus> … derived frm the nested conversation
<bramus> … when we nest groups, some css properties that were previously not that important to capture are now very important because otherwise it looks broken
<bramus> … two groups
<bramus> … - tree effects like opacity, mask, clip-path, filters, perspective
<bramus> … these apply to entire tree
<bramus> … - borders and border-radius because once you have a hierarchy of groups and you have overflow then the overflow affects the origin where you draw the borders and shadows
<bramus> … these also paint after backgrounds
<bramus> … so it comes down to when doing just default capture, nesting is visually broken
<bramus> … but this also was something we discussed when vt started
<bramus> … that animating ?? directly looks better, e.g border and border-radius
<bramus> … than just capturing it as one image and cross-fading it
<bramus> … otoh we already shipped the old thing, so its a compatibility issue
<bramus> … we see three options
<bramus> … 1. change everything by default and dont just capture snapshot but add more things that get captured as ?? instead of a flat snapshot (opacity, filter, transform, bg borders, )
<bramus> … will change things because these styles are part of the group
<bramus> … but have changed things before (but this is different as it changes observable computed style)
<bramus> … 2. add new property `v-t-style` or `v-t-capture-mode`
<bramus> … fane of the first as it reminds me of `transform-style`
<bramus> … 3. to have this new property but give it auto value
<bramus> … if group contains other groups when you get the new mode
<bramus> … so users using nesting get the new mode
<bramus> … but can have a property to change the behavior
<khush> q?
<khush> q+
<astearns> q+
<bramus> … if people want the old crossfade behavior theycan always do so by regular DOM nesting
<astearns> ack khush
<bramus> khush: hoping we can split this in 2 resolutions
<bramus> … 1 on the new capture mode
<bramus> … and 2 to change the default or not
<bramus> q+
<bramus> astearns: confused about third option (adding current capture for non-nested but auto new nested for grouping without giving opt out)
<bramus> noamr: there is an opt out
<bramus> astearns: not entirely sure about backwards compat concern since we ar estill working on this
<bramus> … i’d have to have somebody look at the data
<bramus> … changing mode for non-grouped things seems OK if its better
<astearns> ack astearns
<astearns> ack bramus
<flackr> +1
<fantasai> scribe+
<fantasai> bramus: Yes, this would be breaking, but it would break in a good way
<fantasai> bramus: Regarding the name of the property, one of the values proposed is cross-fade, which is a value I wouldn't recommend
<fantasai> bramus: because authors can change the animation, e.g. to scale-up/scale-down, etc.
<noamr> q+
<fantasai> bramus: I would suggest a different name for the property, view-transition-capture-mode: flat | layered
<astearns> ack noamr
<bramus> noamr: fine with any type of bikeshedding
<bramus> … if we choose option 1 we dont need new property
<bramus> astearns: yet
<bramus> noamr: propably wouldnt need one
<bramus> … if we change default then optoin of using crossfade is always possible with nesting DOM
<khush> q+
<bramus> … defers the conversation about naming it
<astearns> ack khush
<bramus> khush: my vote is for option 1, is risky but can try it with a flag
<ntim> q+
<bramus> … one instance i have seen where it could break things, and partner let us know that they would welcome the change
<astearns> ack ntim
<bramus> ntim: is this changing by default for all capture modes or just nested ones?
<bramus> … i mean, nested or everything?
<bramus> noamr: option 1 is everything, option 3 only for groups
<bramus> … option 1 would be “breaking change” / modification to view transitions 1
<bramus> astearns: and option 3 would not be
<bramus> noamr: i proposed that one as i am very skiddish about backwards compat
<vmpstr> q+
<bramus> vmpstr: also supportive of option 1
<bramus> … future looking this mode seems to be strictly better in a lot of cases (e.g. border radius that animate instead of cross-fade)
<bramus> … one concern is breakages and specifically if Apple is also on board with making this change then we want to do this
<bramus> … want to avoid interop problem where blink switches modes and webkit doesnt
<bramus> … hard to feature detect
<bramus> … and sites would have to deal with two different modes
<bramus> … that is the biggest risk I see
<bramus> astearns: tim, do you have preference?
<bramus> ntim: dont know how fast if we can adopt this
<bramus> … guess if there is a compat concern it maybe is possible?
<bramus> … cant give definitive answer
<bramus> fantasai: we can reasonable say that if this is the direction to go we should … but cant commit to a timescale though
<bramus> noamr: there is some sentiment to 1 but I feel ppl need to think about this more?
<bramus> astearns: could resolve on option 1 and have blink try it out to see how much breakage there is
<bramus> … and if its manageable then we’re good and come back to this
<bramus> … would be resolving one 1 unless it’s not possible
<bramus> … i’d rather not define a new capture mode without a switch
<khush> q+
<vmpstr> q-
<bramus> ntim: do you know how much work this will be for you?
<bramus> noamr: I am prototyping it right now, can report back
<bramus> … doesnt seem like huge amount of work
<bramus> … mainly adding more things to list of captured props and not painting them when element is being captured
<bramus> ntim: OK
<astearns> ac khush
<astearns> ack khush
<bramus> khush: when we prototype we]ll find edge cases
<bramus> … we will take those back to the WG in that case
<bramus> … want to get this right
<bramus> noamr: it involves a lot of CSS props
<bramus> … some of them are captured and not painted, while others are painted
<flackr> q+
<bramus> … the ones specifically would all be specified
<astearns> ack flackr
<bramus> flackr: is it that we need a specific property list or is it that your children are captured as a painting and only props that affect the child dont matter instead of the box that is captured?
<bramus> noamr: depends on how handwavey we want to be
<bramus> … we would need WPTs
<bramus> flackr: just want to avoid situation where it is hard to guess
<vmpstr> q+
<bramus> noamr: there could be general wording plus exceptions
<bramus> astearns: as goes for specifying it should be about its characteristics so that it extends to new future properties
<astearns> ack vmpstr
<bramus> noamr: agreed
<bramus> vmpstr: agree as well
<bramus> … dont want to maintain a list of props for all eternity
<bramus> noamr: could we add it to a property descriptor?
<ntim> q+
<bramus> astearns: we have a lot of things in description tables … if we can avoid addig a field there I would prefer that
<astearns> ack ntim
<bramus> noamr: no strong opinion
<khush> q+
<bramus> ntim: from impl POV it would be good to have list well defined in some way. new field in prop table or whatever workds
<bramus> … to make sure impls dont miss things
<bramus> astearns: for most part weshould be able to define groups of props with some exceptions and then encode things in WPTs
<bramus> … having a list of props in the WPT seems better than in the spec
<astearns> ack khush
<bramus> khush: gonna second what ntim said
<vmpstr> q+
<bramus> … right now spec has UA stylesheet that is very well defined so there is no interop issue there
<bramus> … when having a property descriptor in the prop table makes it easier for interop too
<bramus> … e.g. animatable
<astearns> ack vmpstr
<bramus> … you dont miss it
<ntim> I'm also OK with the list being maintained into a WPT, it just needs to be maintained somewhere
<noamr> q+
<bramus> vmpstr: middle ground could be to define groups of props such as “clipping properties”
<bramus> … and props should add themselves to those groups
<astearns> ack noamr
<bramus> … that might be a nice middle ground, but that’s only a guess right now
<bramus> noamr: can have a default per spec
<bramus> … eg box shadow spec to include sth that says all the props work in one way or the other
<bramus> astearns: elika, do you have an idea?
<bramus> fantasai: like the idea of doing it per spec. will simplify thinking about it
<fantasai> https://www.w3.org/TR/css-backgrounds-3/#placement
<bramus> … other option to put it in propdef table
<bramus> … we current have a ?? so we could have a statement in one of those sections
<astearns> s/??/module interaction sections/
<bramus> s/??/some boilerplate text in module interactions
<bramus> … how x interacts with other modules
<bramus> … or “this also applies to first letter”
<bramus> … can add another paragraph for VTs
<bramus> astearns: how about we specify this in VTs with an explicit list to begin with and a note saying that this info needs to move to individual modules and module interaction section?
<bramus> fantasai: and if vt editors want to work on some PRs to update specs that need that section, that would be welcome in a single PR
<bramus> noamr: OK
<khush> q+
<bramus> fantasai: some specs are missind that section though, so youll need to add it
<bramus> khush: so is the conclusion we have an explicit list but it is define by each module?
<bramus> … it describes which group it belongs to, and then vt handles the group behvior
<astearns> ack khush
<khush> +1
<vmpstr> +1
<bramus> fantasai: yes, but at first you can have an explicity list in the vt spec and then later on group them
<fantasai> once you feel confident in your groupings/descriptions
<bramus> astearns: so propsed resolution is to change capture mode for all view-transitions and specify how each property is affected by this capture mode change
<bramus> … does that sound right?
<bramus> … astearns any concerns?
<bramus> bramus: should we also add that blink will experiemnt and come back with compat concerns?
<bramus> astearns: sounds good
<bramus> RESOLVED: Change the capture mode for all view-transitions and specify how each property is affected by this capture mode change
<bramus> RESOLVED: Blink will experiment and come back with changes needed if there are compat concerns
<fantasai> RESOLVED: describe categorization of properties in the Module Interactions sections of each spec

[noamr]

As part of experimentation, we've identified which properties need to participate in this and how, and also the potential compatibility-breaking parts (though it's not shipped yet, so we don't know if the compatibility breakage happens in practice).

Categorization

We divide CSS properties into the following categories:

Copied

Properties that should be captured, and also be rendered into the snapshot

• overflow
• overflow-clip-margin
• contain (potentially just convert contain: paint into overflow: clip)
• transform-style
• perspective
• box-sizing
  (the last two actually don't have any effect on a flattened snapshot)

Delegated

Properties that should be captured and delegated to the group, and the snapshot should be rendered without them (note that some of these are shorthands):

• background
• border
• border-image
• border-radius
• box-shadow
• clip
• clip-path
• filter
• mask
• opacity
• outline
• padding

Notes

• The transform of the element should be copied in 3D space rather than flattened, to preserve the 3D effect of the origin.
• Applying overflow to the snapshot is a design choice, to avoid capturing very big overflowing content. This means that the author cannot use the pseudo-elements to animate scrolling an overflow: scroll DIV. However, the overflow is captured without the border-radius, which is applied separately as CSS and can be animated, as well as clip-path and clip.
• If we don't render the border, this affects the border box of the pseudo-elements, and its relationship with nested groups, as the border-box is what's used to determine the pseudo element's position. Suggesting that this change means that we need to project the padding box instead.
• The size of the box is captured according to the original element's box-sizing.

Backwards compatibility

The main way this change affect existing pages is likely to be the fact that the ::view-transition-group pseudo-element would now have keyframes that animate many things, which would override styles put directly on the group pseudo. One way to mitigate this can be to add a pseudo element (::view-transition-effect?) between the group and the image-pair that animates these, and keep the pseudo animating only geometry.

This can anyway be good ergonomically as authors can customize one without breaking the other.

[noamr]

One issue that came up while prototyping this is that with the new capture mode, you can't simply hide the old/new state by hiding the old/new pseudo, if the old/new state had backgrounds/borders/etc. And to mimic the current behavior, the author would need to change the HTML hierarchy (add a container element).

I'm not sure if this is a desirable outcome. Indeed layered capture provides a more superior experience, but the flat crossfade capture is simpler: everything is in the old/new elements and you can always hide one of them. I think this is a point towards keeping the old capture mode as an option and making the decision based on a CSS property (which can be the existing view-transition-group property or something new).

[noamr]

Summarizing from internal sync, we're concerned about breaking existing developer expectations around this by changing the default behavior, especially since this is already shipped in Safari and the difference is not feature-detectable.

Proposing, instead, to have this as a new CSS property.
Suggesting the syntax from @bramus's comment earlier in the thread:
view-transition-capture-mode: flat | layered | auto, where flat is the current mode, layered is the new mode, and auto would make a decision based on view-transition-group. Leaning towards having layered as the default and letting current adopters of view transitions try their sites in Canary.

The advantage:

• People can switch to the simpler mode if they wish in an easy way, without having to add new in-between DOM elements
• It makes the new behavior feature detectable via @supports, while there is an interop issue

[khushalsagar]

flat and layered SGTM. I don't think we need auto if layered is the default.

If we're revisiting a new property to switch the mode then worth thinking about how #9406 should fit here. Since we want flat primarily for compat, maybe the third mode should be layered-no-content which caches the styles but skips caching the content snapshot. No need to support no content in flat mode.

[khushalsagar]

Since we want flat primarily for compat

Correction, we did find UX cases like sliding old/new content here: https://view-transitions.chrome.dev/pagination/spa/ which would need the image pseudos to have box decorations like the element background. If the background changes, you might want that to slide instead of interpolating as a style on the group.

[vmpstr]

I don't think we need auto if layered is the default.

+1, switching to a different mode based on view-transition-group relationships will likely add more confusion. flat and layered with layered being the default makes sense to me

[noamr]

For the sake of avoiding endless scrolling, I'm preparing a PR based on the previous resolution, and let's take the opt-in question (alongside followup questions about the details of the capture mode) to new issues.

[noamr]

For the breakout today: see explainer.

Open questions, given our quick backwards compat analysis and prototype

• See that the capture model((properties and geometry) makes sense.
• opt in/out / what's the default ([css-view-transitions-2] how do we decide whether to use layered capture? #11078).
• How to deal with scrollbars ([css-view-transitions-2] Define behavior of scrollbars and overflow with layered capture #11079).

[css-meeting-bot]

The CSS Working Group just discussed [css-view-transitions-2] Optionally capture some properties (e.g. opacity/border) as style instead of snapshot.

The full IRC log of that discussion

<bramus> noamr: talked about capturing snapshots not flat but to also capture borders, shadows, opacity, etc
<bramus> … had homework to figure out the exact way of how this would work and do some compat analysis
<bramus> … have done both to an extent
<noamr> https://github.com/WICG/view-transitions/blob/main/nested-explainer.md#layered-capture
<bramus> … wrote an explainer for this
<bramus> … main question is if this is a net improvement to capturing elements layered or not?
<bramus> … only works when elements are superimposed on eachother in a way, like cross-fade morphs the animation
<bramus> … many people use slide animations, like a header sliding offscreen
<bramus> … when authors do that, capturing the borders separately creates a different effect
<bramus> … backwards compat it wouldnt affect hat many peole right now, but those that are affected are affected in a big way
<bramus> … want to get attention to the explainer
<bramus> … there are afew optoins:
<bramus> … make it an opt-in
<bramus> … or create an extra pseudo for the geometry animation
<khush> q+
<bramus> … it does create more things to think about it, but nice thing about that it is that it does what it does today
<bramus> … you need to only style it if you want to
<bramus> … third option is to have no opt-in and have authors opt-out by containment thorugh adding an extra container element
<bramus> … not looking for a resolution now
<astearns> ack khush
<bramus> khush: +1 to what noam said
<bramus> … am pretty convinced that original capture way might have been a mistake.
<bramus> … noam dug up styles that authors used to customize animatoins and have found slight animations that were set up
<bramus> … if you have two things
<bramus> … where the whole bg changes you dont want those to fade but just want the slide effect
<bramus> … dont want to break those
<bramus> … especially on the root level
<bramus> … also dont want authors to have to create a wrapper around the content int root to fix that
<bramus> … could maybe resolve that both these modes should exist
<bramus> … how to select one or the other can be decided later
<bramus> bramus: +1 on both modes being valuable
<bramus> a+
<bramus> q+
<bramus> astearns: need to read explainer a bit more. wrapper made sense until khushals argument
<bramus> noamr: should generally avoid people to change their dom for style purposes
<bramus> bramus: +1
<astearns> ack bramus
<bramus> bramus: can the extra speudo give a perf benefit?
<bramus> noamr: not really. think of border animating
<bramus> … I encourage ppl to look at the explainer
<bramus> … especially the geometry part, because we copy over the box mode
<bramus> s/mode/model
<bramus> … also scrollbars and stuff
<bramus> … food for a next meeting
<bramus> astearns:thanks for the summary and explainer. its great to have
<bramus> … will summarize the breakout to the www-style list and set up async resolutions and point people to the explainer
<bramus> … gonna wrap up