Repository navigation
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
meta-cla
Bot
added
the
CLA Signed
|
AI review status for this pull request.
|
github-actions
Bot
added
the
needs:design-review
PR Analysis Report📚 Storybook Preview🧪 Sandbox PreviewComponent Size
Sizes are gzip. Import counts the JavaScript the import loads eagerly; CSS counts the package stylesheet rules referenced by the modules it can load from its own package, lazily loaded ones included. Bundle Size SummaryGzip figures measure each package's entry file, not the code an import pulls in.
Accessibility AuditStatus: No accessibility violations detected. Visual Regression55 of 502 shot(s) changed. A change here is a question, not a failure: check whether the after is the
and 35 more. Generated by PR Enrichment workflow | Storybook | Sandbox | View full report |
![astracat-bot[bot]](https://avatars.githubusercontent.com/in/4796231?s=60&v=4){kind=small}
There was a problem hiding this comment.
This pull request is on hold for an owner decision. The UISlider values rest only on the draft spec:AST-094 that this branch adds, so an engineering owner needs to approve or reject that spec, including its proposed changes to the theme-token, press-feedback and scroll-chaining specs, by commenting /approve-spec <full head SHA> here; the author can record this as an engineering owner. Whatever that decision, these need fixing before approval:
- Land #8067 and its predecessors first, then rebase, so the diff is the four-file slider commit instead of 13,263 lines.
- Run the new
pr-interactionjob inside the owning test lane and add it to thetestjoin, as the CI routing spec (spec:AST-030FR11 and FR7) requires, or drop it from this stack. - Get the required
lintcheck green; ESLint runs out of heap at this head. - Fix the animator's Reduce Motion handling, which leaves an interrupted fade at its mid value or at 0 (
animator.ts:1346,animator.ts:1577), and correct the slider comments on the projection rate and the touch target (slider.ts:94,slider.ts:45).
[Automated review]
| # them, so a change to an instrument is proven by its negative controls | ||
| # before a component spec relies on it. Chromium only on these runners; | ||
| # see the harness README for running WebKit. | ||
| pr-interaction: |
There was a problem hiding this comment.
This job routes itself on its own path set (line 3484), and no job lists it in needs, so a failing interaction proof reaches none of the required joins. Current spec:AST-030 FR11 says new coverage inside an existing surface must join that surface's test owner and must not create a separately routed lane, and FR7 says any owned lane failure must fail its join. Run the proofs inside the owning lane and add the outcome to the test join, or get an owner-approved AST-030 amendment.
| ): Partial<Record<MotionProperty, Segment | null>> => { | ||
| const next: Partial<Record<MotionProperty, Segment | null>> = {}; | ||
| const opacityNow = valueAt('opacity', time); | ||
| const opacityTo = targets.opacity ?? opacityNow; |
There was a problem hiding this comment.
When the call has no opacity target, the dip returns to the presentation value, not to the running fade's target. Under Reduce Motion, a move 100 ms into a 0 to 1 fade ends at opacity 0.3577 for good. Use segments.get('opacity')?.target (else the resting value) as the return value.
| changed.push(property); | ||
| if (segment == null) { | ||
| segments.delete(property); | ||
| resting[property] = targets[property] ?? valueAt(property, time); |
There was a problem hiding this comment.
The segment is deleted on the line above, so for an untargeted opacity valueAt returns the stale resting value. With reducedMotion: 'instant' during a fade-in, opacity drops to 0 and the element vanishes (play() repeats this at line 1665). Leave opacity out of next when the call neither targets nor fades it, or read the value before deleting.
| releaseProjectionRate: 0.996, | ||
| /** | ||
| * How much of the projection the coast travels: the target is the lift | ||
| * value plus this share of the projected distance (0.0996 s × the release |
There was a problem hiding this comment.
0.0996 s is this table's 0.996 rate (0.4 × 0.249 s); at the normal rate of 0.998 the share would be 0.1996 s. As written, a consumer could project with projectDistance's default rate and coast twice as far. Suggest "(0.0996 s × the release velocity at releaseProjectionRate)", and drop "as scroll.decelerationRate.normal" at line 86.
There was a problem hiding this comment.
A consumer reading this entry must not coast twice as far. Fixed in 6e0f96c: the comment gives the share as "0.0996 s × the release velocity at releaseProjectionRate", and the rate's entry now says it is not UIScrollView's normal rate (0.998), so it has to be passed to the projection explicitly.
|
|
||
| export const slider = { | ||
| /** | ||
| * The thumb's touch target, a square in pt centered on the thumb: the |
There was a problem hiding this comment.
This entry's own source shows vertical touches tracking only from -20 to +16 pt, inside the 40 pt frame, so the measured target is 48 × 40, not a 48 pt square. Worth recording the frame clip so the touch presentation does not accept touches UIKit ignores.
There was a problem hiding this comment.
The touch presentation should not accept touches UIKit ignores. Fixed in 6e0f96c: the entry now records that UIKit hit-tests inside the control's frame first, so the lab's 40 pt frame clipped the 48 pt target to 48 × 40.
3e47976 to
6e0f96c
Compare
There was a problem hiding this comment.
This pull request is on hold for an owner decision: the UISlider values rest only on the draft spec:AST-094 that this branch adds, so an engineering owner needs to approve or reject that spec, including its proposed changes to the theme-token, press-feedback, input-modality and scroll-chaining specs, by commenting /approve-spec <full head SHA> here; the author can record this as an engineering owner. Whatever that decision, these need fixing before approval:
- Land #8067 and its predecessors first, then rebase, so the diff is the four-file slider commit instead of 13,265 lines; the rebase also clears the
pr-a11yfailure, which comes from the branch predating a spec filemainnow runs. - Run the new
pr-interactionjob inside the owning test lane and add it to thetestjoin, as the CI routing spec (spec:AST-030FR11 and FR7) requires, or drop it from this stack. - Fix the animator's Reduce Motion handling, which leaves an interrupted fade at its mid value or at 0 (
animator.ts:1346,animator.ts:1577). - Add the writing-rubric results for AST-094 to the description, and correct the
dropSpringsource and the comments that point at files absent from this branch.
[Automated review]
| # them, so a change to an instrument is proven by its negative controls | ||
| # before a component spec relies on it. Chromium only on these runners; | ||
| # see the harness README for running WebKit. | ||
| pr-interaction: |
There was a problem hiding this comment.
This job selects itself with its own path set (line 3484), and no job lists it in needs, so a failing interaction proof reaches none of the required joins. Current spec:AST-030 FR11 says new coverage inside an existing surface must join that surface's test owner and must not create a separately routed lane, and FR7 that any owned lane failure must fail its join. Run the proofs inside the owning lane and add their outcome to what ci-test-join.mjs requires, or drop the job until an owner-approved amendment admits it.
| ): Partial<Record<MotionProperty, Segment | null>> => { | ||
| const next: Partial<Record<MotionProperty, Segment | null>> = {}; | ||
| const opacityNow = valueAt('opacity', time); | ||
| const opacityTo = targets.opacity ?? opacityNow; |
There was a problem hiding this comment.
When the call does not target opacity, the dip returns to the presentation value rather than the running fade's target: under Reduce Motion, a move 100 ms into a 0 to 1 fade on springs.smooth ends at opacity 0.3577 for good. Return to segments.get('opacity')?.target (else the resting value).
| changed.push(property); | ||
| if (segment == null) { | ||
| segments.delete(property); | ||
| resting[property] = targets[property] ?? valueAt(property, time); |
There was a problem hiding this comment.
In 'instant' mode crossfade() returns a null opacity even when the call never targeted it, and the segment is deleted on the line above, so valueAt here returns the pre-fade resting value: a move during a fade-in drops opacity to 0 and the element vanishes (play() repeats this at line 1665). Leave opacity out of next when the call neither targets nor fades it, or read the value before deleting.
| * 800 ms hold fitted with one spring (response 0.49 s, damping ratio | ||
| * 0.70, rms 0.10 pt; undershoot to 36.04 pt), Oct 23 2026 | ||
| */ | ||
| dropSpring: {response: 0.5, dampingRatio: 0.7}, |
There was a problem hiding this comment.
This stores response 0.5 s, but the @source above names only the per-frame fit, response 0.49 s, and slider.test.ts:142 calls 0.5 s "the read". Add the read release behavior (0.5 s, 0.7) to the source so the stored value has one.
6e0f96c to
a3052e3
Compare
github-actions
Bot
removed
the
needs:design-review
There was a problem hiding this comment.
This needs an engineering owner's decision before it can be approved: the UISlider values rest on draft spec AST-094, and this head also registers the slider springs as theme-retunable motion roles, which AST-094's FR4 and DEC-1 reject. An engineering owner records that decision by commenting /approve-spec a3052e3db96cae64bc1f7c7e59c18b06820c6c35 on this pull request (the author may do so as an engineering owner), or by saying the slider values should wait for the stacked pull requests to land. Whatever the decision, these need changes:
- Leave this pull request carrying only the two slider commits on top of
main; with the merged stack it changes about 28,700 authored lines. - Under Reduce Motion, a move that interrupts a fade leaves the element at the fade's mid-flight opacity or at its starting opacity (
animator.ts:1399,:1631). uikit.sliderships on@astryxdesign/core/motion/experimental, so it needs an@experimentalmarker and an[experimental]changeset (AST-017 FR21, FR22).- The
platformadaptation condition, the--motion-*theme variables and the separately routedpr-interactionjob contradict current specs AST-012 FR2, theme-tokens INV1 and AST-030 FR7 and FR11.
[Automated review]
|
|
||
| import {registerMotionTable} from '../roles'; | ||
|
|
||
| export const slider = { |
There was a problem hiding this comment.
slider reaches callers as uikit.slider through @astryxdesign/core/motion/experimental (uikit/index.ts:34), but unlike springs, scroll, timing and navigation it has no @experimental JSDoc block. spec:AST-017 FR21 requires every declaration on an experimental surface to carry it.
| * 800 ms hold fitted with one spring (response 0.49 s, damping ratio | ||
| * 0.70, rms 0.10 pt; undershoot to 36.04 pt), Oct 23 2026 | ||
| */ | ||
| dropSpring: {response: 0.5, dampingRatio: 0.7}, |
There was a problem hiding this comment.
The @source above names a per-frame fit at response 0.49 s (rms 0.10 pt), but the stored value is 0.5 s, which slider.test.ts calls "the read" (rms 0.20 pt). Store 0.49, or cite the read 0.5 s in the source so the value and its source agree.
There was a problem hiding this comment.
Fixed in 97dd708: the drop spring's @source now cites the read settings the table stores (0.5 s, 0.7), with the 0.49 s per-frame fit beside them for comparison.
| '@astryxdesign/core': patch | ||
| --- | ||
|
|
||
| [chore] Internal: UISlider's values measured on iOS 26.2 join the UIKit constants table: the thumb's 48 pt touch target, the tracking rule (the value moves by the finger's travel past the pan threshold over the track's length), the release coast's spring, projection rate and share, the thumb's lift and drop springs and scale, and the end-of-track haptic. Its three springs are motion roles a theme can retune (`slider.releaseSpring`, `slider.liftSpring`, `slider.dropSpring`), listed in the motion docs' role table. Not exported from the package entry point; no component uses it yet. |
There was a problem hiding this comment.
At this head the table is public as uikit.slider on @astryxdesign/core/motion/experimental, and its springs are documented theme roles, so "Internal … Not exported" no longer holds. spec:AST-017 FR22 asks for an [experimental] changeset when an experimental surface gains an entry.
There was a problem hiding this comment.
Fixed in 97dd708: the changeset is now [experimental] and names uikit.slider on @astryxdesign/core/motion/experimental, and the table carries an @experimental JSDoc marker that a case checks.
| ): Partial<Record<MotionProperty, Segment | null>> => { | ||
| const next: Partial<Record<MotionProperty, Segment | null>> = {}; | ||
| const opacityNow = valueAt('opacity', time); | ||
| const opacityTo = targets.opacity ?? opacityNow; |
There was a problem hiding this comment.
When the move does not target opacity, the cross-fade ends at opacityNow, the running fade's value at this instant. Under Reduce Motion a 0 → 1 fade interrupted at 100 ms by an x move settles at 0.358 and stays there. Ending at the running segment's target keeps the fade's outcome.
| changed.push(property); | ||
| if (segment == null) { | ||
| segments.delete(property); | ||
| resting[property] = targets[property] ?? valueAt(property, time); |
There was a problem hiding this comment.
The segment is deleted on the line above, so valueAt here returns the value from before the fade: in 'instant' mode the same interrupted fade drops to opacity 0. Read the target (or valueAt) before deleting the segment; play() repeats this at :1717–:1718.
| * is everything else. Pair `ios` with `pointer: 'coarse'` for a touch | ||
| * profile, such as touch motion tuned per platform. | ||
| */ | ||
| platform?: 'ios' | 'other'; |
There was a problem hiding this comment.
spec:AST-012 FR2 closes the condition vocabulary to width, pointer, contrast and motion ("Future environment fields require explicit additions to this closed vocabulary"). platform needs that amendment first, or should leave this pull request.
There was a problem hiding this comment.
This code comes from #8076, the stacked base, so its fix belongs there.
| # them, so a change to an instrument is proven by its negative controls | ||
| # before a component spec relies on it. Chromium only on these runners; | ||
| # see the harness README for running WebKit. | ||
| pr-interaction: |
There was a problem hiding this comment.
pr-interaction routes itself and is not in the test join's needs (:887–:896): on this head test already passed while this job was still queued. spec:AST-030 FR11 asks new coverage to join the existing owners, and FR7 asks every owned lane's failure to fail its join.
There was a problem hiding this comment.
This code comes from #8076, the stacked base, so its fix belongs there.
| useIsomorphicLayoutEffect(() => { | ||
| recognizer.setEnabled(isEnabled); | ||
| }, [recognizer, isEnabled]); |
There was a problem hiding this comment.
Turning isEnabled off mid-gesture cancels the recognizer here and calls the caller's onGesture with cancelled from this layout effect. Per architecture:react-component-runtime INV3, name the system it synchronizes (the recognizer and its gesture host) in a comment beside it.
There was a problem hiding this comment.
This code comes from #8076, the stacked base, so its fix belongs there.
| * and the release coast against the per-frame value after a lift | ||
| * @position Testing; parity of the slider constants (law P4, unit layer). | ||
| * The browser layer is | ||
| * Slider/__tests__/SliderTouch.interaction.browser.spec.ts. |
There was a problem hiding this comment.
Slider/__tests__/SliderTouch.interaction.browser.spec.ts does not exist at this head; drop or reword the reference until that browser layer lands.
There was a problem hiding this comment.
Fixed in 97dd708: the header no longer names a spec that does not exist at this head.
|
Posted by Cindy's agent on her behalf. Parts of this PR re-implement behavior that already exists, or is being specified, as a shared part of core. Converging keeps one implementation per behavior:
This is about where the behavior lives, not about the PR's intent. |
|
Agreed: one implementation.
|
# Conflicts: # packages/cli/test/__golden__/no-icon-set/docs-topics.json
…(spec:AST-094 FR18, DEC-13) A screen-edge pan attached to a stack container, as wide as the screen, with a touch 4 px from its edge: inside the 40.2 px band the pan decides at UIKit's 15 px whatever the element's width, and then tracks the travel past it. From several edges too. Both fail while a wider element decides at FR19's 10 px.
…'s width (spec:AST-094 FR18, DEC-13) FR18: inside the 40.2 px band a screen-edge pan decides at UIKit's 15 px screen-edge hysteresis; outside it the author's scrolling is untouched and FR19's 10 px governs every other claim. The pan decided at 10 px on any element wider than the band, so NavigationStack's edge pan, attached to the stack container, began 5 px early. The edge zone still decides only the touch-action; a touch outside every band still fails at once. The two cases that pinned the 10 px decision go.
…er's move keeps that finger until it lifts) into the experimental touch exports
…than the band (spec:AST-094 FR18, DEC-22) FR18 as amended in meta#8631 (DEC-22): the band's pan-x claim and 15 px start hold only where the screen-edge pan is attached to an element within the band; on an element that reaches beyond it, whose touch-action cannot claim per touch, a touch in the band decides at FR19's 10 px like every other claim. This restores the 10 px decision 3d85c30 removed and keeps 15 px on an element within the band. The cases pin DEC-22 both ways (a wide element with a touch at x=4 begins at 10, an in-band strip at 15, and from several edges at 10 on a wide element); the 10 px cases fail on 3d85c30.
…xperimental touch exports The motion README's Files table is the union: main's rows, with meta#8663's resolveSnapPoint.ts and selectPage.ts, plus this branch's, in main's order. # Conflicts: # packages/core/src/motion/README.md
The gesture README promises that usePressTracker rebuilds its tracker when trackingExpansion, highlightDelay, cancelTravel or quickTapFlash change, from the next touch. That fix (c248459) was lost in a later merge of the press-tracking line: the tracker was built once, so a changed option never applied. It is memoized on those four again; the node attachment, keyed on the tracker, moves to the new one and disposes the old. The callbacks keep being read through the ref on every touch. The new test fails before this change (the same tracker after each option change) and passes after it.
There was a problem hiding this comment.
Approval waits on an engineering owner's decision about Slider's touch direction: spec:AST-094 leaves each component's touch presentation to that component's own record, and component:Slider states none yet (its FR5 still counts a track press, where these values make a tap on the track do nothing, and FR42 sets touch targets at 44 px unless that record sets its own), so these UISlider values need an engineering owner to identify or provide the governing spec, or to approve them as they stand. An engineering owner records that decision by commenting /approve-spec 82c49d3ddf88bb5a4af286342c261df9db380146 on this pull request, and the author may do so as an engineering owner. Separately, please land #8076 first or drop its merge so this pull request carries only its four slider files: the merged copy is a commit behind #8076, and its gesture host conflicts with spec:AST-094 FR18 (GestureHost.ts:497-528 writes over an author's touch-action) and FR20 (GestureHost.ts:1619-1653 lets any scroll take a still finger). slider.test.ts:11 cites an undefined “law P4”, and motion/README.md does not yet list uikit/slider.ts as the barrel's SYNC note asks.
[Automated review]
… s of wall clock
The two proofs that a Reduce Motion dip held before its first frame
still lands (after the hold is finished, and after it is resumed) polled
the box for 2 s of wall clock. On a loaded machine the page's main
thread ran the dip's next step late and the poll ran out first: one
WebKit run read {opacity: 0, translate: 'none'} with four WebKit
containers on the box, then passed in 530 ms on a rerun. They now wait
until the box runs no animation, on the animations' own finished
promises (including the fade back in the dip starts when its fade out
ends), and then assert the landed state. The test's own timeout still
bounds them.
With a 2.5 s main-thread block induced right after the release, both
proofs failed before this change (Timeout 2000ms exceeded while waiting
on the predicate) and pass after, 3 runs each in Chromium.
Main merged meta#8045 and meta#8046. The one conflict is utils/pressFeedback.ts: it takes main's merged meta#8046 text (the finger and button slots, the mouse and key press) and keeps this pull request's own additions, the one writer of the press attribute (writePress, paintPress, readPressPaint) and the header line naming them.
# Conflicts: # internal/interaction-harness/README.md # internal/interaction-harness/src/busy.test.ts # internal/interaction-harness/src/busy.ts # internal/interaction-harness/src/frames.ts # internal/interaction-harness/src/harness.interaction.browser.spec.ts
Main's button slot, merged with meta#8046, ends a press's release at once when the next press starts, by clearing the press attribute directly. On a row another painter holds, that clear erased the hold, which this pull request's one writer refuses. A mouse press on a held row, released, then a press elsewhere must leave the row held. Fails until the early end goes through the one writer.
finish() writes none through writePress, as this pull request's controller paints, so a held row stays its owner's when the next press ends a release early, under the finger and the button slots alike.
Both upstream heads are folded onto main 70ea859 (her meta#8045 frame evidence and meta#8046 coarse press): meta#8446 takes main's harness files, and meta#8073 carries the press controller onto meta#8046's slots. meta#8076 has no change of its own in either set of files, so the merge takes theirs with no hand resolution, and meta#8076 is clean against main again.
…ads it Slider's touch presentation (meta#8190) reads the table, and a release that ships both would print the old line in its notes. The changeset now says only that the table is not exported.
There was a problem hiding this comment.
Approval waits on an engineering owner's decision about Slider's touch direction: spec:AST-094 leaves each component's touch presentation to that component's own record, and component:Slider states none yet, so these UISlider values (a 48 pt thumb target where FR42 keeps 44 px, a track that ignores a tap where Slider's FR5 counts a track press, three springs FR4 admits as roles only through Slider's record, and an end haptic whose iOS Safari gap FR23 asks that record to state) need an engineering owner to identify or provide the governing spec, or to approve them as they stand. An engineering owner records that decision by commenting /approve-spec ca43ceece94bd061b233229c19e11f1a6ed5a7ba on this pull request, and the author may do so as an engineering owner. Separately, please land #8076 first or drop its merge so this pull request carries only its four slider files:
- The merged #8076 gesture host conflicts with
spec:AST-094FR18 (GestureHost.ts:497-528writes over an author'stouch-action) and FR20 (GestureHost.ts:1619-1653lets any scroll take a still finger). slider.ts:41-42says touch motion has no theme surface, which current AST-094 FR4 and DEC-15 andspec:AST-108contradict.- Smaller:
slider.test.ts:11cites an undefined “law P4”, andmotion/README.mddoes not yet listuikit/slider.tsas the barrel'sSYNCnote asks.
[Automated review]
| * Every value is an internal constant: touch motion has no theme surface, | ||
| * and `spec:AST-094` FR4 names no slider role. |
There was a problem hiding this comment.
“touch motion has no theme surface” no longer matches current spec:AST-094: FR4 says a theme's tempo scales durations and its character offsets bounce through per-role weights (spec:AST-108 FR3), and DEC-15 makes those three knobs the theme's way into touch motion. Saying instead that these springs stay plain constants until Slider's record admits them as roles (FR4, DEC-5), after which tempo and character reach them, keeps a reader from playing them as literals FR4 forbids.
| * simulator, capture b40): the value per `valueChanged` against the | ||
| * tracking rule, the thumb's lift and drop against its per-frame width, | ||
| * and the release coast against the per-frame value after a lift | ||
| * @position Testing; parity of the slider constants (law P4, unit layer). |
There was a problem hiding this comment.
“law P4” is defined nowhere in the repository or in current spec; citing spec:AST-094 FR2 and FR3, the claims this test checks, would point readers at the rule.
| } from './gestures'; | ||
| export {navigation, registerNavigationTable} from './navigation'; | ||
| export {registerScrollTable, scroll} from './scroll'; | ||
| export {slider} from './slider'; |
There was a problem hiding this comment.
This makes slider the first component table in the barrel. The branch's tableImports.test.ts (L156–186) fails any component entry that reaches a non-shared table only through a barrel, and motion/README.md:65 shows component authors importing springs from this barrel, so the first component to follow that example fails the guard. Importing slider by path where Slider uses it and leaving component tables out of the barrel (or changing the README example) avoids that. The SYNC note above also asks for uikit/slider.ts in motion/README.md's file table, which does not list it yet.
| element.style.getPropertyValue(property), | ||
| ); | ||
| } | ||
| element.style.setProperty(property, value); |
There was a problem hiding this comment.
This writes the recognizers' derived touch-action over the element's own value. Current spec:AST-094 FR18 requires the derived value to be “intersected with the element's own author touch-action” and never wider than it (DEC-8), so a tap recognizer on a pan-y element would hand horizontal panning and pinch-zoom back to the browser. This code comes from #8076, where the fix belongs.
| } | ||
| } | ||
| if (taken.length > 0) { | ||
| this.arena.browserTookOver(taken, time); |
There was a problem hiding this comment.
Any scroll event hands every unclaimed touch inside the scroller to the browser, however far that finger has moved, and GestureHost.test.ts:823-832 asserts it for a finger that never moved. Current spec:AST-094 FR20 counts a native scroll as taking a touch “only once that finger has moved the scroll take distance”, 10 px, and DEC-8 rejects “cancelling at the first scroll event”. This code comes from #8076, where the fix belongs.
Depends on #8076 (at 6f994bc). Review only this PR's change: vjeux/astryx@6f994bc...ca43cee
User need
Part of Astryx's UIKit-parity work (
spec:AST-094), which makes touch presentations behave as on iOS. #8190 makes a Slider under a finger track like UISlider, and needs UISlider's real numbers: FR1–FR3 require a touch presentation's values to come from the UIKit constants table, each with its source.Problem and solution fit
motion/uikit/slider.tsholds UISlider's values on iOS 26.2, each with its measurement:Current specification
spec:AST-094FR1–FR3.component:Slidersets no touch physics.Public delta and caller burden
None: an internal table (
[chore]), unread here; touch motion has no theme surface.Design and alternatives
valueChangedmatches the travel rule to 10⁻⁴.Evidence
A UIKit host app on the iOS 26.2 simulator (iPhone 17 Pro, real touches) logged
valueChanged, the thumb's frames and four releases. The coast fits within 0.11 pt rms; a 126.9 pt/s release travelled 12.56 pt after the lift, against 12.64 pt predicted.Scope
Testing
Data only; #8190 is its first reader. To check it:
motion/uikit/slider.ts: each value names its measurement.pnpm exec vitest run --project ui packages/core/src/motion/uikit:slider.test.tsreplays the logged drags and releases (tracking, lift and drop, coast) and holds the table to no Reduce Motion mode.Run on this head: the UIKit table tests pass (196), and typecheck and lint are clean.