The previous round regressed the demo against main: dropped frames while
a finger drags, and swipes ignored when they start imperfectly.
Frame drops: hosts used touch-action: manipulation plus a blocking
touchmove listener, so Chrome waited for JavaScript on every touch move
(~30% of frames over 20ms in a drag, p95 28ms). Hosts again use per-axis
touch-action like main (pan-y for horizontal gestures, and so on), and
attach no touch listener.
Flaky recognition: an irreversible decision after 6px dropped swipes
with a wobbly or backward start. Recognition again measures from the
pointer-down point until the pointer lifts, as on main.
Scrolling beside gestures, natively:
- .from.scrollEdge() uses direction-specific touch-action while its
scroller is at the edge (pan-x pan-down for drag-down at the top), the
pull-to-refresh pattern from the Pointer Events spec. A passive scroll
listener keeps it current; no touch handling blocks the browser.
- Where directional values are unsupported (Safari), scroll-edge
gestures alone fall back to claiming touches at the browser's first
cancelable touchmove.
- Hosts publish touch-action as --nvo-touch-action and the stylesheet
applies it to descendants, so nested scroll containers keep it and
horizontal swipes over lists are not cancelled. Ignored subtrees get
touch-action: auto back.
- Bindings gain listeners and ref (spread on the host); the components
use them.
Feel tests (npm run test:feel): Chromium with emulated touch checks
recognition on ten human-like traces, frame pacing budgets while
dragging (p95 <= 20ms, <= 5% over 20ms) for a swipe and a scroll-edge
dismiss, and the behaviour checks. Against the previous code they fail
on exactly the reported regressions; now 23/23 pass. On the demo, all
traces match main and drag frame pacing matches or beats it.
Commit thresholds are unchanged (0.25 distance, 0.2 flick).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Faarh2Ts6StJPcz2mRiHiR
From an app built on core-v2:
Scrolling (#3, #4, #14)
- Each recognizer locks onto a touch within its first 6px: along its axis
and direction it holds the touch, otherwise it lets go. A new
onTouchmove binding cancels native scrolling only while a recognizer
holds the touch, so hosts use touch-action: manipulation and one
vertical gesture no longer disables vertical scrolling. Several
gestures on one host share touches through the same rule.
- .from.scrollEdge(scroller, edge) admits drag-to-dismiss only while a
scroller is at the edge (#5).
Feel
- recognition.distance sets what counts as full progress: pixels, a CSS
length, or a measuring function (#6).
- Choreographies receive overshoot, the drag past either end of the
clamped progress, and the settling spring starts from it (#7).
- Velocity is the least-squares trend of the last 100ms (#8).
- Defaults retuned to commitThreshold 0.25 and commitVelocity 0.2; the
slide presets use them (#9).
- Choreographies may set spring stiffness and damping (#10).
Hooks and helpers
- .onArm()/.onDisarm() run during a drag when releasing would start or
stop committing (#12).
- startedIn, nearEdge, atScrollEdge, anyOf, allOf start predicates (#15).
- Development builds warn when an operation's first frame moves a node
that was visibly at rest, the one-frame "pop" of mismatched open and
close choreographies (#16).
Docs: scrolling, ignored elements, animation performance, haptics, and
operating-system edge gestures including CloseWatcher/popstate for PWAs
(#11, #17, #18).
Verification: a Chromium harness with emulated touch (verify/browser)
checks swipes over scrollers, native scrolling beside gestures,
scroll-edge dismissal, onCommit inside pointerup, and the continuity
warning. Reverting the earlier capture fix makes it fail exactly as
reported ("none of the handles work").
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Faarh2Ts6StJPcz2mRiHiR
Claude