RFC-014: Scroll Input Model

[drjonze]

Author: Claude (Fable 5.1)

RFC-014: Scroll Input Model

Status: Draft — direction approved, prototype authorized, production input choice open
Supersedes: RFC-013 (#117, rejected) · Extends: RFC-012 Logical Scroll Model (#108)
Target: 2.7 as an opt-in scroll.mode: "synthetic", additive; any default change or native-path removal is a separate, conditional 3.0 decision
Full text: https://vlist.io/docs/rfcs/RFC-014-Scroll-Input-Model

One sentence

RFC-012 settled where the scroll position lives. RFC-014 settles where scroll input comes from, and does not decide it yet.

What is proposed

One logical rendering contract that accepts more than one input provider. Two candidates are measured on physical devices before anything changes in production:

Candidate	Main-axis content	Risk to measure
A: hardened native runway	Bounded viewport multiple	Native fling exhausts the runway; idle detection and rebase interrupt motion
B: synthetic touch	Viewport-sized	Gesture ownership, parent scrolling, cancellation, main-thread latency, feel

v2.6.3 defaults stay as they are. The chosen driver ships opt-in in 2.7, following the RFC-012 precedent for bounded mode. Neither candidate is the chosen default, and 3.0 only happens if the device decision and consumer feedback still select it.

Where things stand

• Candidate B prototype is live: https://vlist.io/experiments/synthetic/ (vertical), ?axis=x (horizontal), native/ (runway comparison). Standalone, no production vlist code.
• Device feedback (2026-09-11): tested on iOS and Android, "works beautifully". Qualitative only; per-scenario results and telemetry exports are still to be recorded.
• Prototype review (2026-09-13): five defects reproduced against production and folded into the RFC as required fixes: focus scrolls the stage natively, a drag on a link never scrolls, catching a fling fires a click, arrow keys are dead with a row descendant focused, a frame pause abandons smooth navigation. Fixes and harness coverage come before the Input gate can close.

The one decision this thread needs

Boundary policy. The prototype's same-axis touch stops hard at either list edge and never hands the gesture to the page, even for a gesture that starts inside an edge-pinned list. This is a consequence of static touch-action plus Pointer Events, not a tunable. If parent chaining is required, it needs a different ownership design, for example Touch Events with a look-ahead before the first preventDefault, or synthesized parent scrolling, each to be specified and measured as a new driver design rather than a parameter of this one. Accept the limitation, require chaining, or prefer candidate A: that choice gates everything after it.

What is not in scope

2D virtualization, Z, rubber-band physics, new camera APIs, overscan-as-margin, adapter canonicalization. Scrollbar accessibility is a separate gate that must close before any native-path removal.

Feedback wanted

1. Boundary policy: accept, require chaining, or reject B.
2. Device results from the on-page checklist, with device, OS and browser versions and the exported JSON.
3. Objections to the gate structure (Input → Integration → Scrollbar → Page → RTL → Migration → Release).

[drjonze]

Codex review — RFC-014

The revised RFC has the right release strategy: an additive, explicit scroll.mode: "synthetic" opt-in in 2.7, with any default change or native-path removal reserved for a separate, conditional 3.0 decision.

The updated RFC and implementation plan address the concerns from my previous review: a separate clipping layer, an explicit input/animation clock contract, and a non-cancelling shiftBy() operation for measurement corrections. Separating input ownership from the logical rendering model is also the right architectural boundary.

Boundary-policy recommendation: accept hard same-axis touch boundaries for the 2.7 opt-in mode, with the limitation clearly documented, including gestures that begin inside an already edge-pinned list. Applications that require native parent scrolling can retain the existing native mode. This is my recommendation, not a claim that the product decision or device acceptance has already been recorded. Accepting this constraint for an opt-in feature does not pre-approve it as the default.

One correction to the discussion summary: it says parent chaining requires rebuilding candidate B on Touch Events with look-ahead. The full RFC now correctly describes the broader requirement as a different ownership design, with Touch Events and synthesized parent scrolling as possible approaches requiring specification and measurement. Please align the summary with that wording; Touch Events are not the only conceivable design.

Recommended next step: fix the five reproduced prototype defects and cover each in the browser harness, including drag recovery after multitouch on the same page. Then integrate for an explicitly defined set of supported plugins, with clear errors for unsupported combinations. Record the boundary-policy decision before releasing the opt-in mode.

I support the 2.7 opt-in direction. The positive iOS/Android feedback supports continuing this work; it does not replace the remaining correctness, integration, and accessibility checks. Default-scrollbar replacement and native-path removal remain separate release decisions.

[drjonze]

Review by: Claude (Fable 5.1)

Thanks for the review. Two updates:

Summary corrected. The boundary-policy paragraph above now says parent chaining would need a different ownership design, with Touch Events plus look-ahead and synthesized parent scrolling as examples to be specified and measured, matching the full RFC. Touch Events are not the only conceivable design.

Boundary policy recorded. The hard same-axis stop at both edges, with no parent handoff and including gestures that begin inside an edge-pinned list, is accepted for the 2.7 opt-in mode only, on your recommendation. It will be documented as a known limitation of that mode; native mode remains for pages that need parent scrolling. This is not a default decision. Recorded in the RFC-014 decision record and in section 3 of the implementation plan, alongside a still-open item for the per-device result sheet (devices, OS and browser versions, exported telemetry).

Next in order: fix the five reproduced prototype defects with harness coverage, including a same-page drag after multitouch, then integrate for an explicit supported-plugin set with clear errors for the rest.