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

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).