[cixzhang]

Maintainer impact

• People dragging a Slider with a finger, a pen or a mouse move the thumb from where they grabbed it, by how far they move after 10 px; a press on a thumb alone never changes the value.
• A tap or click on the track still sets the value (a finger on lift, a mouse at once), so dragging is never the only pointer path (WCAG 2.2 SC 2.5.7).
• After a finger lifts, the thumb coasts and settles (about 0.6 s, on a named motion role), and onChangeEnd fires when it stops, with the value on screen. Mouse and pen drags end at release.
• Product teams: no prop or API change. Under a finger, a flick's onChangeEnd now arrives after the coast settles (about 0.6 s). Ships as a patch [fix] by the owner's ruling (2026-11-01: "touch timing: I don't think these are breaking. Can you name a desirable scenario?").

Exact decision needed

How every pointer drags a Slider thumb, and when a finger's drag ends.

Existing authority searched

component:Slider (FR1–FR6, ORD2, DEC-1–DEC-3), spec:AST-094 (FR4, FR9, FR13, FR19, FR42, FR43), spec:AST-017 (FR1, FR3, FR28, FR31, FR53, DEC-25), spec:AST-020/FR15, spec:AST-085, design:reduced-motion, design:user-states, architecture:public-component-api INV16. None states how a pointer drags a thumb or when onChangeEnd fires after a coast; Slider's record owns both.

Decision

The owner chose these on 2026-11-01: every pointer tracks from the grab point, and a finger's release coasts with onChangeEnd at its end.

• FR5 amended: after a finger's release, onChangeEnd fires once its coast settles.
• ORD2 amended: onChange continues through a finger's coast; onChangeEnd reports the rendered value once the thumb has stopped.
• FR7 added: every pointer drags a thumb by its travel past a 10 px movement threshold (not a zone around the thumb); a press on a thumb changes no value; a finger or pen claims only along the track; a coarse pointer gets a 48 px target and a lift; a finger's release coasts on the springs.sliderRelease motion role (touch only); track tap/click still sets the value; reduced-motion behavior. Marked as an implementation gap.
• DEC-4 added: why one tracking model for every pointer, why the coast is touch only, and how the single-pointer alternative is kept.
• Compatibility: a patch [fix] by the owner's ruling (2026-11-01). No desirable use depends on the released drag: a thumb press that jumps the value is a defect, a slow drag still ends at the lift, and onChangeEnd still carries the value the person sees settle; only a touch flick's onChangeEnd arrives later.
• Verification: FR7 row (pending touch and fine-pointer browser tests in Chromium and WebKit).

This unblocks #8189, #8190 and #8669, which rebase onto it and name their rule FR7 in the record's current folder. #8168 is to be dropped: #8190 already carries its translate-based movement.

Rejected alternatives

• A mouse keeping today's jump to the pointer (one Slider, two drags by device).
• A finger's drag ending at the lift with no coast.

Claim scope and non-goals

Pointer tracking, the finger's coast and onChangeEnd timing only. Keyboard (AR1), anatomy, theming targets and Tooltip/Field composition are unchanged. Focus placement after a finger drag is not decided here.

Evidence and implementation relationship

UIKit measurements of UISlider (target, threshold, release spring, projection share) and the before/after browser tests in the implementation pull requests above. No implementation in this PR.

Writing rubric results

• R1 narration: none; the new FR7, DEC-4 and compatibility bullets are present tense about the system.
• R2 research in the record: none; measurements stay in the motion table, and DEC-4 keeps one sentence of conclusion.
• R3 evidence naming a change: none; FR7's basis is "UIKit measurements and maintainer decision (DEC-4)", and its verification row names the test layer.
• R4 rejected alternatives over one line or outside a decision: one, in DEC-4, one line.
• R5 pull request or issue references remaining: none in the record.
• R6 ruled open questions still listing options: none; OQ1 is unanswered and unchanged.

Scope

• This PR contains specification records only.
• It records observable behavior and preserves equivalent internal implementations.
• Any named internal mechanism is intentionally public, names its dependent caller/system, and explains why an equivalent implementation would not satisfy the contract.
• Verification states the evidence layer and failure signal without prescribing CI job/workflow topology.
• It records one intentional durable decision, not a rescue for a separable tagalong.
• The canonical knowledge owner, affected current claims, and overlapping open work are named; any ownership collision is resolved or called out for human decision.
• Adjacent API, visual, accessibility, composition, and implementation facts remain outside scope unless this exact decision depends on them.
• Public text and artifacts contain no internal Meta context.

Validation

• pnpm install --frozen-lockfile
• pnpm check:knowledge: Knowledge templates and records are aligned.
• Prettier: clean
• git diff --check: clean

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
astryx	Ready	Preview	Nov 2, 2026 12:58am UTC

[astracat-bot]

AI review status for this pull request.

Review status	Updated
🔄 In progress (for maintainers only)	Nov 2, 2026, 12:49 AM UTC

[cixzhang]

/approve-spec 5458551

[cixzhang]

/approve-spec 4c022ba