spaces: the drags, the pinch and the menus a phone could not reach

Four of this app's gestures were mouse-only, and three of them were absent on a
touch screen rather than merely awkward: reordering a block, nesting a page and
moving an issue card are HTML5 drag-and-drop, which never fires from a finger,
and a canvas card's grip listened for mousedown. Nesting a page had no fallback
at all.

New spaces/src/touch.ts. Press-and-hold synthesises the dnd events the existing
handlers already listen for — a real DataTransfer, dragstart on the source,
dragover/dragleave/drop on whatever is under the finger — so every drop rule and
every highlight in editor.ts is reached unchanged, and a fourth draggable thing
gets touch support with no edit there. The canvas grip is replayed as the mouse
stream it already handles. A finger that moves before the hold is scrolling and
nothing is preventDefault-ed, so scrolling is untouched. Holding at the edge of
a scroller drags the view along, because at 390px one of the board's six columns
is on screen.

Also measured on the built shell at 390x800 and fixed:

- The Insert menu laid out 19 items 1000px tall with five below the viewport and
  no way to scroll; the More menu lost its last five the same way. Both cap and
  scroll now. Not a phone-only bug: the last Insert item was off an 860px laptop
  window too.
- The graph could be panned by one finger and never zoomed - wheel was the only
  zoom. Two fingers zoom about the point between them; the second finger also
  ends the one-finger drag it interrupts.
- A board or wide table that ran out of content handed the rest of a sideways
  swipe to the browser's back gesture. Contained.
- "Wide" is 80% of the window, which left a 257px column inside a 390px phone.
  It takes the whole width below 850px and is byte-identical above it - measured
  at 1400px, 872px before and after.
- The sharing button was 35x29 where every other bar control is 40x40 on a
  coarse pointer.

Desktop is untouched by construction: everything added is a touch listener, a
coarse-pointer rule, or a class that only exists during a touch drag. No new
strings, so no catalog work.

Author: nyblnet

spaces/CHANGELOG.md

@@ -477,6 +477,47 @@ Versions follow `0.MINOR.PATCH` while pre-1.0.
   2026, from the same file. `bento.journal()` opens today's for an agent, and
   `bento.journal('2026-08-06')` any day's.
 
+- **A finger can do the four things only a mouse could.** Reordering a block,
+  nesting a page in the tree, moving an issue card between columns and moving a
+  card on a canvas were all mouse-only: the first three are HTML5
+  drag-and-drop, which never fires from a touch, and the fourth listened for
+  `mousedown`. Two had a fallback (Move up / Move down in the block menu; tap a
+  card's status chip) and **the page tree had none** — nesting a page was
+  impossible on a phone by any route. Press and hold now starts the same drag,
+  and holding a card at the edge of a board or a list scrolls it along, since at
+  390px only one of six columns is on screen at a time.
+
+  A finger that MOVES is still scrolling. Nothing is captured until the press
+  has been held still, so a swipe that starts on a card scrolls the page exactly
+  as it did before.
+
+- **Pinch to zoom the graph.** One finger already panned it, but zoom was on the
+  scroll wheel alone — so on a phone the one view whose whole point is a crowded
+  picture could be shoved around and never scaled. Two fingers zoom about the
+  point between them and pan at the same time; the second finger also ends the
+  one-finger drag it interrupts, so the two gestures no longer fight.
+
+- **A menu taller than the window has items nobody can reach.** Measured on a
+  390×800 phone: Insert laid out 19 items 1000px tall, putting Table, Link to
+  the web, Image and Video or audio 253px below the screen with no gesture that
+  reaches them — the menu is positioned inside a fixed bar, so the page cannot
+  scroll to them. ⋯ lost its last five the same way. Both scroll now, and this
+  was never only a phone bug: on an 860px laptop window the last Insert item was
+  off the bottom too.
+
+- **A sideways swipe stops at the edge of what it is scrolling.** A board or a
+  wide table that runs out of content handed the rest of the gesture to the
+  browser, which on a phone is the back-navigation swipe. It ends where the
+  board does.
+
+- **A wide page stops giving away a third of a phone.** "Wide" is 80% of the
+  window, which is a sensible proportion on a desktop and 283px on a 390px
+  phone — with the block gutter's 26px that left a 257px column inside a 390px
+  screen. It takes the whole width below 850px and is unchanged above it
+  (measured at 1400px: 872px before and after). And the sharing button, alone
+  among the toolbar's controls, was 35×29 rather than the 40×40 every other one
+  gets on a touch screen.
+
 ## [0.1.0] — 2026-08-03
 
 First release.

spaces/src/canvas.ts

@@ -62,6 +62,7 @@ import { descendantsOf, newBlock } from './model.ts'
 import { sanitizeInline } from './sanitize.ts'
 import { t } from './i18n.ts'
 import { ICONS } from './icons.ts'
+import { touchDragAsMouse } from './touch.ts'
 
 /** The surface's shape, width ÷ height. Wide, because the first thing anyone
  *  draws here is a row of steps. */
@@ -428,6 +429,11 @@ function wireCard(card: HTMLElement, body: HTMLElement, hooks: CanvasHooks): voi
   card.appendChild(grip)
 
   grip.addEventListener('mousedown', (down) => startDrag(down, card, body, id, hooks))
+  // AND A FINGER DRIVES THE SAME GESTURE. The mouse choice above is right and
+  // none of its reasoning is about input hardware, so a touch is replayed as
+  // the mouse stream it already handles rather than forked into a second drag
+  // with its own clamps and its own commit. See touch.ts.
+  touchDragAsMouse(grip)
 
   // THE KEYBOARD MOVES IT TOO. A surface reachable only by mouse is a surface
   // half this app's readers cannot use, and the same clamp and the same commit

spaces/src/editor.ts

@@ -19,6 +19,7 @@ import { syncNoticeText } from './syncnotice.ts'
 import { Store } from './store'
 import { renderPage, toneLabel, paintCode } from './render'
 import { wireCanvas, placeNewCard } from './canvas.ts'
+import { enableTouchDrag } from './touch.ts'
 import { CODE_LANGS, langLabel, normLang } from './highlight'
 import { canonicalize, escText, sanitizeInline, textOf } from './sanitize'
 import { FormatBar } from './formatbar'
@@ -535,6 +536,13 @@ export class Editor {
       }, true)
     }
 
+    // A FINGER GETS THE DRAGS A MOUSE HAD. Blocks, page rows and issue cards
+    // are all `[draggable="true"]`, and HTML5 dnd never fires from a touch —
+    // so press-and-hold replays the same dnd events those handlers already
+    // listen for. One call, delegated at the root, so anything draggable this
+    // editor grows later is covered without a second edit. See touch.ts.
+    enableTouchDrag(this.root)
+
     this.paintTree()
     this.paintPage()
     this.syncHistoryButtons()

spaces/src/graph.ts

@@ -43,6 +43,7 @@
 import type { SpacesDoc, SpaceIndex } from './model.ts'
 import { ICONS } from './icons.ts'
 import { t } from './i18n.ts'
+import { enablePinchZoom } from './touch.ts'
 
 // ————— the graph itself ————————————————————————————————————————————————————
 
@@ -764,6 +765,23 @@ export function openGraphView(opts: GraphViewOpts): GraphView {
     draw()
   }, { passive: false })
 
+  // ——— two fingers ———
+  //
+  // One finger already worked: the pointer path above is pointer events, and a
+  // touch drives those. ZOOM did not — it was `wheel` alone, and a phone has no
+  // wheel, so a crowded graph could be shoved around and never scaled. Fit was
+  // the only way to change magnification and it only ever gives you one.
+  //
+  // The second finger also has to CANCEL the one-finger drag it interrupts, or
+  // the pointer path keeps panning (or worse, keeps dragging a node) underneath
+  // the pinch and the two fight over the same picture.
+  canvas.addEventListener('touchstart', (e) => { if (e.touches.length > 1) drag = null }, { passive: true })
+  enablePinchZoom(canvas, {
+    get: () => ({ scale, panX, panY }),
+    set: (s, x, y) => { scale = s; panX = x; panY = y; draw() },
+    limits: [0.12, 5],
+  })
+
   fitBtn.addEventListener('click', () => { fit(); draw() })
   closeBtn.addEventListener('click', () => opts.close())
   back.addEventListener('click', (e) => { if (e.target === back) opts.close() })

spaces/src/render.ts

@@ -954,7 +954,16 @@ export function renderPage(page: Page, doc: SpacesDoc, opts: RenderOpts = {}): H
   // 80% keeps a visible step at every size, and the 1500px cap keeps Wide from
   // becoming an unreadable line on a very large screen — at which point Full is
   // the thing to pick, deliberately.
-  else if (width === 'wide') inner.style.maxWidth = 'min(1500px, 80%)'
+  // …WITH A FLOOR, because a proportion has nothing to be a proportion OF on a
+  // phone. 80% of a 354px page is 283px, and the 26px the gutter takes there
+  // leaves a 257px column on a 390px screen — a third of the display given to
+  // margin on the setting whose entire purpose is "room for a board or a
+  // table", and reachable in one tap ("Use this width for every page" is a
+  // per-screen preference). `max(80%, 680px)` is the same 80% wherever 80% is
+  // at least 680px (a container of 850px and up) and the whole container below
+  // that, since a max-width wider than the box does nothing. Measured at 390px:
+  // column 257 → 328, the page's left margin 79 → 26.
+  else if (width === 'wide') inner.style.maxWidth = 'min(1500px, max(80%, 680px))'
   else if (doc.theme.measure) {
     // AND THE DEFAULT ITSELF GROWS. 720px is ~88 characters at 16px, which is
     // already at the long end — so this does not widen the line much; what it

spaces/src/styles.css

@@ -706,7 +706,10 @@ button.sp-callout-chip:hover { text-decoration: underline; text-underline-offset
 /* A WIDE TABLE SCROLLS. The measure belongs to the document, so a six-column
    table must not widen the prose column on a phone — it gets its own scroller
    and the paragraph above it keeps its line length. */
-.sp-tb-wrap { overflow-x: auto; position: relative; }
+/* `overscroll-behavior-x` for the reason spelled out on `.sp-board`: a
+   sideways swipe that runs out of table must stop, not become the browser's
+   back gesture. */
+.sp-tb-wrap { overflow-x: auto; overscroll-behavior-x: contain; position: relative; }
 .sp-tb {
   width: 100%; border-collapse: collapse; table-layout: fixed;
   font-size: 15px; line-height: 1.5;
@@ -1460,15 +1463,61 @@ button.sp-callout-chip:hover { text-decoration: underline; text-underline-offset
 /* Hit targets: a 30px button is a miss on a touch screen. */
 @media (pointer: coarse) {
   .sp-bar .sp-btn { min-width: 40px; min-height: 40px; justify-content: center; }
+  /* The sharing button is a `.sp-live`, not a `.sp-btn`, so the rule above
+     stepped straight over it: measured at 320px with the coarse rules applied,
+     five bar controls came out 40×40 and this one 35×29 — the odd one out, and
+     the one that opens a popover. Widening it does not cost the bar its fit:
+     Save's right edge stays at 311 inside 320. */
+  .sp-bar .sp-live { min-width: 40px; min-height: 40px; justify-content: center; }
   .sp-dditem { padding-block: 11px; }
 }
 
+/* WHILE A FINGER IS DRAGGING. The press that starts a touch drag is also the
+   press that arms text selection on iOS and Android, and a card whose title is
+   being selected mid-drag paints a blue smear across the gesture. touch.ts
+   clears the selection when the hold fires; this stops a new one starting. */
+body.sp-touchdrag, body.sp-touchdrag * { -webkit-user-select: none; user-select: none; }
+/* AND SCROLL SNAPPING STANDS DOWN WHILE IT LASTS. The board's
+   `scroll-snap-type: x proximity` is right for a thumb flicking between
+   columns and wrong for the 12px-per-frame creep that carries a held card
+   towards an off-screen column: each step lands inside the proximity of the
+   snap point it just left and is pulled straight back. Measured before this
+   rule, with the finger parked at the board's right edge for 1400ms:
+   scrollLeft 0 → 0. */
+body.sp-touchdrag .sp-board { scroll-snap-type: none; }
+
 /* A menu opened from the right end of the bar must open INWARD. Anchoring
    every dropdown to its start edge put the ⋯ and Save menus half off-screen at
    375px — the items were there, just unreadable. */
 .sp-dd-end .sp-ddmenu { inset-inline-start: auto; inset-inline-end: 0; }
 .sp-ddmenu { max-width: calc(100vw - 20px); }
 
+/* A MENU TALLER THAN THE WINDOW IS A MENU WITH ITEMS NOBODY CAN REACH.
+   Measured on the built shell at 390×800: Insert laid out 19 items 1000px tall
+   with its bottom at y = 1053, so five of them — Table, Link to the web, Image,
+   Video or audio and the divider above them — were 253px below the viewport;
+   ⋯ laid out 928px with its bottom at 981. The menu is `position: absolute`
+   inside a fixed bar, so the page cannot be scrolled to them and there is no
+   gesture that reaches them at all. Not a phone bug, either: at 861px of
+   browser height on a laptop the same five items are off the bottom.
+
+   `100dvh`, not `100vh`: on a phone `vh` is the tall viewport with the URL bar
+   retracted, so a cap written in `vh` still runs the menu under the chrome that
+   is actually on screen.
+
+   BOTH AXES ARE SPELLED OUT ON PURPOSE. Setting one to a non-`visible` value
+   computes the other to `auto`, and a scroll container CLIPS what is positioned
+   inside it — a floating child can never escape one (CLAUDE.md's ⋯/Share
+   popover trap, which cost slides a silently half-drawn popover). Every child
+   of these menus today is a `position: static` `.sp-dditem`, verified in the
+   built shell: 16 of 16 in ⋯, 19 of 19 in Insert. Anything demoted in here
+   later must be a SECTION OF THE LIST, never a popover anchored to it. */
+.sp-ddmenu {
+  max-height: calc(100dvh - 64px);
+  overflow-y: auto; overflow-x: hidden;
+  overscroll-behavior: contain;
+}
+
 /* ————— find & replace on a small screen —————
    Measured at a 575px viewport: the bar laid out 644px wide and started at
    x = -87, so the Find field itself was off the left edge — the one control
@@ -1787,6 +1836,14 @@ button.sp-prop-val:hover { background: var(--surface); border-color: var(--edge)
 .sp-board {
   display: flex; gap: 12px; overflow-x: auto; padding-bottom: 6px;
   scroll-snap-type: x proximity;
+  /* …AND THE SWIPE STOPS AT ITS OWN EDGE. `overflow-x: auto` keeps the board's
+     columns out of the document, but by default a touch scroll that reaches
+     the end of a scroller CHAINS to its ancestors — and on a phone the
+     outermost ancestor is the browser's own back-navigation gesture. Measured
+     at 390px: the board holds 1452px of columns in a 257px box, so a reader
+     swiping through five columns hits that end on nearly every gesture.
+     Containment ends the scroll where the board does. */
+  overscroll-behavior-x: contain;
 }
 .sp-col {
   flex: 0 0 232px; min-width: 232px; scroll-snap-align: start;
@@ -1852,7 +1909,7 @@ button.sp-issue-set:hover { background: var(--chrome-2); border-color: var(--edg
    the rest as data: tabular figures, a quiet rule under the head, and no
    vertical lines — a grid of boxes is a spreadsheet, and this is a list of
    documents that happens to have columns. */
-.sp-view-tablewrap { overflow-x: auto; margin: 0 0 4px; }
+.sp-view-tablewrap { overflow-x: auto; overscroll-behavior-x: contain; margin: 0 0 4px; }
 .sp-view-table {
   border-collapse: collapse; width: 100%; font-size: 13.5px;
   font-variant-numeric: tabular-nums;