The Shape control it got last commit did nothing, and the reason is the trap that
file already warns about: `contentFor` is a per-kind allowlist and everything it
does not name is dropped. `subject-cover` was not in it, so the panel wrote a
ratio, got a 200, and the API stored `{}`. Its own comment says that is "exactly
what silently threw `ratio` away when the admin first sent one".
Now it holds a ratio and a crop, and the block gets the same framing surface the
About Us hero has.
Two things it does NOT get, both deliberate:
No Change and no Remove — `fixed` on MediaField. The picture is the subject's
first carousel item and this block cannot store a different one. Framing is its
decision; which photograph is not.
No local knowledge of which picture that is. The site answers
`/pages/:id/subject-lead`, because which template draws which section, which row
is the example and which of its pictures leads are four facts that live in
templates.ts — a second copy here is how the two drift when a fifth template
arrives.
And it says out loud that the crop applies to every row the template draws. It is
framed against one photograph and used on all of them, which is the one
surprising thing about cropping a template rather than a page.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The panel frames a 21:9 header in a 200-pixel thumbnail while the real one is on screen six inches
away, in the layout it belongs to. Dragging the picture itself is the obvious control, and until now
it was also the expensive one: every new rectangle made the site cut a fresh ladder — nine widths, two
formats, 1.54s measured — with the preview waiting for it.
Both halves are gone. The site draws the rectangle in CSS in development (previous commit, other
repo), so a framing costs nothing to show; the drag here is inline styles on the picture, and the only
write is one PATCH when the hand stops.
Inline styles rather than the site's custom properties, because the site renders a FRAMED picture one
way and an untouched one another — and an untouched photograph is exactly the one somebody is about to
drag. Inline beats both, and beats the object-fit the unframed path leaves behind, which would
otherwise crop the picture a second time inside a box that is already the crop.
Attached to every shaped photograph rather than to the selected one. Selection would put itself in the
paint's dependencies, so choosing a block would repaint the whole page's chrome; this way onDocument
still depends on the sections alone. The cost is that a click could become a nudge, so nothing moves
until the pointer has travelled 3px — below that it is a click, it selects the block, and no crop is
written.
The panel's zoom buttons now reach the real picture too, through `onDraft`. Otherwise the thumbnail
and the page would disagree for the 600ms until the debounce lands, which reads as a broken control
rather than a delayed one.
crop.ts is new and is the reason this is safe: parseCrop had already been copied once, and a crop that
means one thing in the panel and another on the page is a bug you can only feel. MediaField now draws
its own preview through the same `rectToBox`.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
MediaField is controlled: it reports every pointer move and draws what it is
handed back. Wired straight to the block, that was a PATCH and a full reload of
the preview per move, and the page went white while somebody dragged.
The drag runs against local state now — instant — and the write is debounced by
useAutosave, the same hook every other control here uses.
The reset effect keys on the url and the shape, not on the crop. Keyed on the
crop it would fight the drag: the parent's value is the last SAVED one, so every
move would snap back until the save landed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
pastilhasandClaude Opus 5