The palette was not enough colour, and it was never going to be. What it replaced — the browser's own
picker — is the full colour space with an eyedropper in it, and it only ever failed because of WHERE it
was: at the right-hand edge of a narrow panel, where its popup opened off the side of the window.
So the controls move to the block instead of the picker being rebuilt. A toolbar pinned to the selection
frame, in the middle of the picture, where the native popup has room. Above the frame, or below it when
the block sits near the top edge — a toolbar drawn off the top is the same unreachable control again.
Everything is on it now: size, alignment as three buttons rather than a select, colour, and delete. The
row per overlay under the canvas is gone. It was a second place to look — the block up here, the thing
that changes it down there — and every adjustment cost a glance each way.
The text is typed where it appears. Double-click, or the pencil. The contentEditable is uncontrolled on
purpose: re-rendering its children from state replaces the text node the caret stands in, so the caret
jumps to the end on every keystroke. The DOM owns the text while it is being typed and the effect only
writes back when the two have genuinely diverged.
Three things that follow from editing in place. A press on a block being edited places the caret and
does not start a drag. Enter is prevented, because a <br> does not survive textContent and the break
would vanish on save — width decides the breaks, as it already did. Paste is forced to plain text,
because a contentEditable takes markup whole and none of it can be stored or drawn.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
It was `<input type="color">`, and the browser's own picker is a window-level popup positioned by the
browser. In a panel near the right edge it opened off the side of the window and could not be reached —
and nothing in CSS can move it, because it is not in the document.
Swatches and a hex field instead, in a panel anchored to the RIGHT of its trigger so it grows inward
and cannot leave the screen the same way.
Deliberately not a gradient area and a hue strip. That is what the native control does well, and
rebuilding it badly to fix a positioning problem would be a worse control than the one being replaced.
Text over a photograph is white or black almost every time; the hex field is there for the times it is
not.
Closes on `pointerdown` anywhere else rather than `click`, so it closes on the way down and a press
meant for something behind it does not land twice. Captured, because a control below may stop
propagation for its own reasons.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Clicking a block selects it: an outline appears, its row below highlights with it, and a handle on the
edge it grows from resizes the box. Clicking the picture deselects, which is how somebody says "none of
them" without hunting for a button.
Only the selected one is outlined. Every block framed at once turns the picture into a wireframe and
hides the thing actually being judged, which is how the text looks ON the photograph.
The block now has a width, and that is what fixes the dragging. Without one it was as wide as its
longest line, so it changed shape as it was typed and there was nothing stable to take hold of. Text
wraps inside the box now, so a line break is a decision rather than an accident of the current text.
The handle follows the alignment — on the left for a right-aligned block — because it belongs on the
edge the box grows from, and dragging it inwards would otherwise shrink from the wrong side. Its grab
area is four times the visible bar: a 3px target is a target nobody hits.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The wireframe puts two blocks of text on the header picture. The page had one `phrase`, drawn under it.
`header_overlays` is a jsonb list — `[{ text, x, y, size, color, align }]` — rather than a pair of
`header_text_1_*` columns. The design asks for two today; a third is then data rather than a migration,
and nothing has to decide what an empty second block means. `headerPhrase` is left alone: folding them
together would silently move somebody's existing copy on top of a photograph.
Everything is relative and has to be. x and y are percentages of the picture, so a position means the
same thing on a phone and a desktop. `size` is a percentage of the picture's WIDTH, because a headline
set at 40px is a headline on a laptop and a caption on a large screen. The preview renders that with
container query units against the picture's own box, which is exactly what the percentage means — the
page will do the same, so the two cannot drift.
The editor is the picture with the text on it, at the shape the page uses, because where a line sits on
a photograph is not a decision anybody can make from two number fields.
The API clamps every field rather than rejecting: a position into the picture, a size into something
legible, the colour to a hex triple. A caller sending nonsense gets a usable overlay instead of a 400,
and the page can never be handed a position that puts text off the edge of its own header.
Pushed to both databases and verified by querying information_schema rather than by reading db:push's
exit code, which is documented to lie.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
pastilhasandClaude Opus 5