motion.div layout animation: layout prop (FLIP from the last painted rect) and shared layoutId

[Ernxst]

Request

Two props on motion.div, matching the motion package's API so the web build maps onto it through the existing conditional import and the same component tree animates identically on both renderers:

• layout: when the node's own rect changes because of layout (content re-fit, sibling insertion, reflow), animate position and size from the last painted rect to the new one. FLIP over the layout engine's result: the layout runs to completion, the node is painted with a transform and size offset that starts at the old rect and eases to zero.
• layoutId: a node unmounting in one place and mounting elsewhere with the same id animates between the two rects (the moving highlight behind an active tab).

Why

A dock with an auto-sized pill around a nav whose active label changes, and a highlight that moves to the active tile, currently measures every rect with getBoundingClientRect after commit, keeps the numbers in React state, and animates numeric widths and positions, on both platforms. With layout and layoutId the component declares intent and deletes the measurement. #408 (auto-size width tween) is the width-only special case and would still leave the web build measuring, since CSS cannot animate auto to auto; this request replaces it.

Scope notes

• Rust owns the interpolation like the existing motion.div target animations: React sends the props once, the renderer tracks the last painted rect per node (and per layoutId) and requests frames until settled.
• transition applies as it does for target animations; springs included.
• Reduced Motion follows the existing motion.div behavior.
• First paint of a node is not animated; a layoutId match on mount is.
• Scale-vs-resize semantics for children need a decision (the motion package defaults to scale correction on the parent and offers layout="position" / "size"); the minimum useful subset is layout (position + size) and layoutId.

Reported from a downstream app; subsumes #408.

[Ernxst]

Deferred until the backlog has nothing consumer-facing left. Design evidence from a read-only investigation at main b3b4582 (zed pin a64a7e49), so it starts warm later.

What exists. motion.div folds initial/animate/transition into one nested motion prop; Rust owns the clock, easing and spring sampler, retargeting, reduced motion and frame scheduling (packages/native/src/motion.rs). MotionProps.animate is required and there are no layout/layoutId fields; the host config drops unknown props, so a layout-only motion.div cannot reach native today. Paint records bounds per element, but nothing retains a previous-frame rect and nothing survives element destruction.

Position is cheap, size is not. GPUI's element-offset stack (Window::with_element_offset, the Anchored pattern) shifts paint, hitboxes, automation bounds and accessibility together without touching layout, so layout="position" is a contained addition. Size projection is not available: Quad, Shadow, paths, underlines and polychrome sprites carry no transform; only glyph sprites and Svg do, and Svg's is render-only. There is no transform stack on Window. A correct position-and-size FLIP therefore needs a composable transform stack carried through prepaint, paint, clips, hitboxes, accessibility and scene replay, with transformed geometry in every primitive on Metal, WGSL and HLSL. That is #195's parked work and the largest divergence from upstream zed the fork would carry.

Web. There is no motion/react import, no motion dependency and no web component variants in this repo; the browser build is the same Rust compiled to wasm. The conditional import mentioned above lives in the consumer app if anywhere, so web parity is theirs to confirm or a separate deliverable here.

Recommended shape when this is picked up: milestone B first.

• B1: animate optional; layout?: boolean | "position", layoutId?: string; native per-element previous-painted-rect state; layout="position" via an offset wrapper. First paint does not animate; deterministic via advanceAsyncClock (Test renderer: advanceAsyncClock does not deliver requestAnimationFrame callbacks synchronously #411).
• B2: layout={true} animates size through the existing width/height channels driven by committed layout changes (siblings reflow during the run, documented; visually identical to FLIP for absolutely positioned nodes such as a dock highlight).
• B3: layoutId registry per renderer: one outgoing snapshot per id retained through the next completed paint, consumed once by the first incoming mount, then expired; strict-styles diagnostic for two live owners; the incoming node's transition governs; no crossfade.
• B4: scroll compensation (a scroll offset delta is not a layout change), virtual-list rows outside the painted set have no rect, README, a consumer example replacing getBoundingClientRect measurement.

Milestone A (the GPUI transform stack, replacing B2's size channel with a projection and scaling children as the motion package does) is declined unless a consumer case appears that B visibly gets wrong: an in-flow node whose siblings must not move while it resizes.

Other settled recommendations: animate (x, y, width, height) in logical pixels with the existing sampler, keep base and visual rects separately, retarget from the current visual rect; measurement, hit-testing and accessibility follow the visual rect; an explicit animate width/height keeps its channels and layout supplies position only; accept device-pixel snapping of offsets. Risks to carry into B1: zero-sized target axes, spring overshoot below zero, retarget loops when an explicit width animation keeps changing layout, registry leaks without a paint generation.