feat(studio): fit-to-children button for automatic element sizing

[miguel-heygen]

Summary

Adds a fit-to-children icon button next to the W/H fields in the property panel's Layout section. Clicking it computes the bounding box union of all visible children and resizes the parent element to fit — like Figma's "Resize to Fit" or After Effects' "Fit Comp to Layer".

Why BCR union instead of CSS fit-content

CSS `fit-content` collapses to the intrinsic content size (text width, image dimensions), which is wrong for composition elements. In a video composition, children are typically absolute-positioned divs with explicit dimensions — `fit-content` on the parent collapses to zero because absolute children don't contribute to the parent's intrinsic size.

The BCR (bounding client rect) union approach measures the actual rendered bounds of all visible children via `getBoundingClientRect()` and sets the parent's width/height to encompass them. This works correctly regardless of positioning mode, transforms, or CSS layout.

Implementation

• On click, iterates `element.children`, filters to `nodeType === 1` (elements), skips zero-size children
• Computes `{minX, minY, maxX, maxY}` union of all child BCRs
• Calls `onSetManualSize(element, { width, height })` with the computed dimensions
• Button only appears when `element.capabilities.canApplyManualSize` is true
• Icon: dashed box with corner bracket marks (SVG, 14×14)

Test plan

• Select an element with visible children → fit button appears next to W/H
• Click fit button → element resizes to encompass all children
• Undo (Cmd+Z) reverts the size change
• Button hidden for elements without `canApplyManualSize`
• Works on elements with absolute-positioned children

Stack: 4/4 — depends on #1223

[miguel-heygen]

• feat(studio): fit-to-children button for automatic element sizing #1224 👈 (View in Graphite)
• feat(studio): wire snap engine into preview drag and resize gestures #1223
• feat(studio): snap guide overlay, toolbar, grid, and target collection #1228
• feat(studio): Figma-quality snap engine for preview canvas alignment #1227
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[james-russo-rames-d-jusso]

Summary: "fit to children" icon button next to W/H in the property panel's Layout section. Click → computes the BCR union of element's nodeType === 1 children and calls onSetManualSize(element, { width, height }) with the rounded extents.

Small, focused PR with a thoughtful PR body (the "why BCR instead of fit-content" preamble is exactly the right archaeology context for the next reader). No blockers — a couple of concerns about coordinate-space handling and one UX gap, plus standard nits.

Concerns

• BCR is viewport-relative, not composition-pixel-relative. getBoundingClientRect() returns post-transform coordinates. If the studio's iframe document is rendered with any transform / zoom (and studioUiPreferences.previewZoom exists, so zoom is at least a stored concept), the union's maxX - minX is in overlay pixels, while onSetManualSize's { width, height } is presumably interpreted in composition pixels — those diverge whenever the user is not at 100% zoom. snapTargetCollection.collectSnapContext in #1228 handles the same divergence by dividing by rootScaleX = iframeRect.width / rootWidth; mirroring that pattern here is the safe bet. Worth confirming the studio's rendering model first — if the scale is applied outside the iframe (host-page CSS transform on the iframe element), then iframe-internal BCRs already land in composition pixels and you're fine.
• No parent reposition. If a child has its top-left at (-50, -50) relative to the parent's current top-left, minX/minY capture the child's outside-the-parent bound, and the resulting width / height are correct — but onSetManualSize only sets width/height, not position, so the parent stays at its current (left, top) and the child still hangs off the top-left corner. Figma's "Resize to Fit" + AE's "Fit Comp to Layer" both reposition. The PR title ("encompass all children") suggests reposition was the intent; the implementation only resizes. Either scope the PR to "grow-only fit" (and rename to make that explicit) or thread a position commit through too.
• No visibility filter. snapTargetCollection.collectVisibleElements in #1228 calls isElementVisibleForOverlay(child) so visibility: hidden and zero-area-via-CSS children are skipped. Here, only zero-BCR children are skipped (which catches display: none because BCR is 0×0, but not visibility: hidden, which still lays out and has a non-zero BCR). The PR body says "all visible children" — worth matching that with the same visibility predicate.

Nits

• Button is rendered whenever canApplyManualSize is true, but does nothing when children.length === 0. Better UX: render the button disabled with a tooltip ("No children to fit to") so the user gets feedback instead of a silent no-op. (nit)
• title="Fit to children" carries the label, but screen readers' handling of title is inconsistent. Add aria-label="Fit to children" for AT users; keep title for hover. (nit)
• Type predicate (c): c is HTMLElement => c.nodeType === 1 over-narrows — nodeType === 1 is the Element check; SVGElement is also nodeType 1. Compositions can contain SVG (icons, vector marks). BCR works on Element regardless, so no functional bug; the cast is just a small lie to the type checker. Either widen the predicate to Element or filter to instanceof HTMLElement if SVG is intentionally excluded. (nit)
• Inline onClick is ~20 lines of click logic — extract to handleFitToChildren = useCallback(...) (or a plain handler in the parent's hooks layer) for readability and so the logic is exercisable by a future test. (nit)
• The Test plan's "Works on elements with absolute-positioned children" item is the load-bearing one — that's the case where fit-content would fail (per PR body) and where the BCR-union approach earns its complexity. A vitest smoke test of the click handler (mocked element with three positioned children, assert onSetManualSize called with the computed extents) would catch most of the concerns above cheaply. (nit)

Questions

• Is the studio's iframe ever rendered with an internal transform (zoom-via-iframe-document-transform) rather than via host-page CSS transform on the iframe element? Determines whether the BCR coordinate-space concern is real or theoretical.
• Reposition intent (concern #2) — grow-only fit, or full-fit-with-position?
• onSetManualSize — does it emit a single undo entry, or one per axis? (Affects the Test plan's "Cmd+Z reverts" item.)

What I didn't verify

• The studio's iframe rendering model / where the zoom transform lives.
• onSetManualSize's signature + side effects (undo behaviour, validation, async commit).
• Whether element.element is always an iframe-internal node (vs. occasionally a host-page node) — assumed iframe-internal per the rest of the stack.
• Cross-realm BCR behaviour for SVG-in-HTML children in compositions.
• Live behaviour at non-100% preview zoom (no setup).

— Rames D Jusso