Polish items deliberately cut from the initial text-element PR. Each is independently shippable.
1. Mid-edit style changes
Today the inline editor's outside-tap overlay is full-screen, so tapping a ContextBar chip while typing commits the editor instead of changing the style. Need a scoped overlay that excludes the toolbar's bounds — or auto-select the editing element so ContextBar's selection intents target it.
2. Double-tap on existing text → edit
Today only the ContextBar "Edit" button reopens the editor on a selected text. Standard UX is double-click / double-tap on the element. Wire onDoubleTap in DrawBox's gesture handler to emit an Event.TextEditRequested(id) (or similar) that the host listens for.
3. Multi-text selection style merge
showTextControls currently requires a single selected text (selectedTexts.singleOrNull()). With a multi-text selection the ContextBar hides text chips. Decide a merge policy (show first element's style; "mixed" indicator when values diverge; apply on click) and surface.
4. Rotation correctness on text
Reported as broken during testing. Code trace looks correct (chrome rotates via withTransform({ rotate(rotation, pivot = bounds.center) }), layout cache is rotation-invariant, gesture math matches other element types). Needs a repro / video to nail down whether it's a render bug, a hit-test miss, or a chrome positioning issue.
5. Inline editor commit semantics
Currently: any press outside the BasicTextField commits. Worth considering:
- Esc to cancel without committing (revert to pre-edit text).
- Commit on focus loss (covers IME and platform window-blur paths).
- Configurable commit policy on
InlineTextEditor so embedders pick.
6. Tap-to-edit existing text via SELECT + click on already-selected
tldraw / Figma pattern: first click selects, second click (when already selected) opens the editor. Cheap UX win, no double-tap timer required.
Related
Spec: #74
Polish items deliberately cut from the initial text-element PR. Each is independently shippable.
1. Mid-edit style changes
Today the inline editor's outside-tap overlay is full-screen, so tapping a ContextBar chip while typing commits the editor instead of changing the style. Need a scoped overlay that excludes the toolbar's bounds — or auto-select the editing element so ContextBar's selection intents target it.
2. Double-tap on existing text → edit
Today only the ContextBar "Edit" button reopens the editor on a selected text. Standard UX is double-click / double-tap on the element. Wire
onDoubleTapinDrawBox's gesture handler to emit anEvent.TextEditRequested(id)(or similar) that the host listens for.3. Multi-text selection style merge
showTextControlscurrently requires a single selected text (selectedTexts.singleOrNull()). With a multi-text selection the ContextBar hides text chips. Decide a merge policy (show first element's style; "mixed" indicator when values diverge; apply on click) and surface.4. Rotation correctness on text
Reported as broken during testing. Code trace looks correct (chrome rotates via
withTransform({ rotate(rotation, pivot = bounds.center) }), layout cache is rotation-invariant, gesture math matches other element types). Needs a repro / video to nail down whether it's a render bug, a hit-test miss, or a chrome positioning issue.5. Inline editor commit semantics
Currently: any press outside the
BasicTextFieldcommits. Worth considering:InlineTextEditorso embedders pick.6. Tap-to-edit existing text via SELECT + click on already-selected
tldraw / Figma pattern: first click selects, second click (when already selected) opens the editor. Cheap UX win, no double-tap timer required.
Related
Spec: #74