Repository navigation
fix(DateInput, DateTimeInput): the calendar's toggle and selection follow UIDatePicker's timing - #8206
fix(DateInput, DateTimeInput): the calendar's toggle and selection follow UIDatePicker's timing#8206vjeux wants to merge 2160 commits into
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 PreviewModified ComponentsDateInput (@astryxdesign/core) · View in Storybook
DateTimeInput (@astryxdesign/core) · View in Storybook
TimeInput (@astryxdesign/core) · View in Storybook
Component 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.
|
| Component | JavaScript | CSS |
|---|---|---|
| core/DateInput | +46.4KB |
+355B |
| core/DateTimeInput | +48.9KB |
+444B |
| core/PowerSearch | +48.3KB |
+384B |
| core/TimeInput | +29.7KB |
+19B |
Bundle Size Summary
Gzip figures measure each package's entry file, not the code an import pulls in.
| Package | Entry (ESM) | Entry gzip before | Entry gzip after | Delta |
|---|---|---|---|---|
| @astryxdesign/core | 4.9KB | 1.2KB | 1.2KB | 0B |
| Package stylesheet | Gzip before | Gzip after | Delta |
|---|---|---|---|
| @astryxdesign/core | 34.6KB | 34.9KB | +337B |
Accessibility Audit
Status: No accessibility violations detected.
Visual Regression
55 of 502 shot(s) changed.
A change here is a question, not a failure: check whether the after is the
picture you intended. Record that review on the PR. Baseline maintenance is an
explicit dispatch of CI; this report never rewrites the baseline or adds a release gate.
| component | story | theme | mode | pixels |
|---|---|---|---|---|
| Selector | Indicator Space Bottom Sheet Narrow End RTL | neutral | light | 753,933 |
| Selector | Indicator Space Bottom Sheet Wide Start | neutral | light | 740,072 |
| RichTextEditor | Markdown parity: side by side | probe | dark | 558,840 |
| RichTextEditor | Markdown parity: side by side | probe | light | 540,756 |
| Chat | Full AI Chat | probe | light | 230,823 |
| Chat | Full AI Chat | probe | dark | 229,805 |
| AppShell | With Mobile Nav | probe | light | 217,010 |
| AppShell | With Mobile Nav | probe | dark | 216,960 |
| Collapsible | Dividers | probe | dark | 66,445 |
| Collapsible | Dividers | probe | light | 66,445 |
| AppShell | Playground | neutral | dark | 65,198 |
| AppShell | Playground | neutral | light | 63,788 |
| Chat | Default | neutral | dark | 36,304 |
| Chat | Default | neutral | light | 35,767 |
| Chat | Empty State | probe | light | 23,531 |
| Chat | Empty State | probe | dark | 22,622 |
| ChatAutoScroll | Scroll Behavior Comparison | neutral | dark | 15,378 |
| ChatAutoScroll | Scroll Behavior Comparison | neutral | light | 14,107 |
| Chat | With Attachments | probe | light | 13,406 |
| Chat | With Attachments | probe | dark | 11,232 |
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.
Approval waits on an engineering owner's decision. The calendar toggle's timing moves from the theme's motion tokens to UIKit constants under draft AST-094 (FR1, FR4), which would narrow the current theme-tokens architecture (INV3) for touch presentations, and the reading-direction chevron that turns down has no governing spec yet. An engineering owner records that decision by commenting /approve-spec <full head SHA> on this pull request once the records say what is approved; the author may do so as an engineering owner. Whatever is decided, these need changing:
- Land the stacked predecessors first, so this pull request's compare holds its own 371-line commit instead of 36,310 lines.
- Make the
lintcheck pass: ESLint runs out of memory on this head but passes onmain. - Add real-browser evidence for DateTimeInput's new cross-fade and chevron turn and for the RTL chevron (AST-013 FR10), since the browser spec covers only the DateInput story in LTR.
- Tag
.changeset/calendar-toggle-uidatepicker-timing.md[feat]rather than[fix]and name the old chevron, because it changes visual direction (AST-017 FR3).
[Automated review]
| '@astryxdesign/core': patch | ||
| --- | ||
|
|
||
| [fix] The calendar in the DateInput and DateTimeInput bottom sheets now follows the iOS date picker's timing: |
There was a problem hiding this comment.
This entry describes an intentional change of visual direction (a new chevron glyph and new motion timing) that no current visual authority covers, so AST-017 FR3 calls for [feat] rather than [fix]. FR3 also asks the entry to name the old appearance: a down chevron that flipped up.
There was a problem hiding this comment.
See the newer thread: the body records the visual direction as proposed, pending owner review.
| const ease = cubicBezier(...timing.curves.easeInOut); | ||
|
|
||
| async function openCalendar(page: Page) { | ||
| await openStory(page, storybook(), 'core-dateinput--bottom-sheet-calendar'); |
There was a problem hiding this comment.
Only the DateInput story is opened here, in LTR. DateTimeInput's new cross-fade and chevron turn, and the mirrored chevron in RTL, are paint changes too (AST-013 FR10). Running the same samples against a DateTimeInput presentation: 'bottom-sheet' story and with the RTL direction global would cover them.
There was a problem hiding this comment.
Fixed in 0fbbb07: the spec now covers DateTimeInput's cross-fade curve and the mirrored chevron in RTL.
856179f to
93d2ed7
Compare
There was a problem hiding this comment.
Approval waits on an engineering owner's decision: the calendar toggle's timing moves from the theme's motion tokens to UIKit constants under draft AST-094 (FR1, FR4), which would narrow the current theme-tokens architecture (INV3) for touch presentations, and the reading-direction chevron that turns down has no governing spec yet. An engineering owner records that decision by commenting /approve-spec <full head SHA> on this pull request once the records say what is approved; the author may do so as an engineering owner. Whatever is decided, these still need changing:
- Land the stacked predecessors first, so this pull request's compare holds its own 371-line commit instead of 36,158 lines.
- Tag
.changeset/calendar-toggle-uidatepicker-timing.md[feat]rather than[fix]and name the old chevron, because it changes visual direction (AST-017 FR3). - AST-094 FR7 cites AST-090, which only #8003 proposes, so land that first or qualify the sentence.
[Automated review]
| follows. | ||
| - **FR7 — Exits animate as UIKit's do.** A touch presentation MUST play the | ||
| exit its UIKit counterpart plays. **Proposed; pending owner review:** this | ||
| departs from the draft `spec:AST-090` FR1 (exits off by default) and FR10 |
There was a problem hiding this comment.
There was a problem hiding this comment.
At 0fbbb07 this branch no longer edits docs/specs/AST-094.
93d2ed7 to
b2a1fa4
Compare
b2a1fa4 to
f80dc69
Compare
There was a problem hiding this comment.
Approval waits on an engineering owner's decision: the calendar toggle's timing moves from the theme's motion tokens to UIKit constants under draft AST-094 (FR1, FR4), which would narrow the current theme-tokens architecture (INV3) for touch presentations, while the reading-direction chevron and keeping the full 250 ms fade and 90° turn under Reduce Motion (draft FR8) have no governing spec yet. An engineering owner records that decision by commenting /approve-spec <full head SHA> on this pull request once the records say what is approved; the author may do so as an engineering owner. Whatever is decided, these still need changing:
- Land the stacked predecessors first, so this pull request's compare holds its own 671-line commit instead of 36,863 lines.
- Tag
.changeset/calendar-toggle-uidatepicker-timing.md[feat]rather than[fix]and name the old chevron and the old 0.01 s Reduce Motion timing, because it changes visual direction (AST-017 FR3). - AST-094 FR7 cites AST-090, which only #8003 proposes, so land that first or qualify the sentence.
[Automated review]
|
|
||
| [fix] The calendar in the DateInput and DateTimeInput bottom sheets now follows the iOS date picker's timing: | ||
|
|
||
| - The month/year toggle cross-fades in 0.25 s on iOS's ease-in-out curve. It used to be a theme-speed linear fade in DateInput and instant in DateTimeInput. With Reduce Motion on, the fade and the chevron's turn keep their timing, since neither travels. |
There was a problem hiding this comment.
People with Reduce Motion on go from a toggle that finished in 0.01 s to a 250 ms fade and a 90° chevron turn, so "keep their timing" reads as no change. Naming the old 0.01 s timing here, and the old down chevron below, would let release-note readers see what changes for them (AST-017 FR3).
There was a problem hiding this comment.
Fixed in 0fbbb07 per design:reduced-motion. Under a finger the toggle is a 200 ms opacity cross-fade and the chevron dips instead of turning; with a mouse it changes at once.
There was a problem hiding this comment.
Approval waits on an engineering owner's decision: the calendar toggle's timing moves from the theme's motion tokens to UIKit constants under draft AST-094 (FR1, FR4), which would narrow the current theme-tokens architecture (INV3) for touch presentations, while the reading-direction chevron and keeping the full 250 ms fade and 90° turn under Reduce Motion (draft FR8) have no governing spec yet. An engineering owner records that decision by commenting /approve-spec <full head SHA> on this pull request once the records say what is approved; the author may do so as an engineering owner. Whatever is decided, these still need changing:
- Land the stacked predecessors first, so this pull request's compare holds its own 1,001 lines instead of 37,193.
- Attach an iOS simulator recording of the CSS fade jumping after a busy commit, or keep the fades as CSS transitions, because moving them into an Effect needs that Mobile Safari evidence (component-style-authoring INV2, AST-013 FR10).
- Tag
.changeset/calendar-toggle-uidatepicker-timing.md[feat]rather than[fix]and name the old chevron and the old 0.01 s Reduce Motion timing (AST-017 FR3). - AST-094 FR7 cites AST-090, which only #8003 proposes, so land that first or qualify the sentence.
[Automated review]
| ): (element: HTMLElement | null) => void { | ||
| const {ref, animator} = useAnimator({initial: {opacity: isShown ? 1 : 0}}); | ||
| const shownRef = useRef(isShown); | ||
| useIsomorphicLayoutEffect(() => { |
There was a problem hiding this comment.
This Effect now owns the toggle’s opacity instead of a CSS transition. architecture:component-style-authoring INV2 keeps a transition CSS can derive out of Effects unless CSS cannot derive it, and the only reason given is a Mobile Safari jump after a busy commit, which spec:AST-013 FR10 says needs evidence from that browser. The busy-commit proof in MonthYearToggle.interaction.browser.spec.ts passes with a CSS fade in Chromium and Playwright WebKit by its own comment. An iOS simulator recording of the previous CSS fade jumping would settle it; otherwise the CSS transitions can stay.
There was a problem hiding this comment.
Agreed: the toggle is back on CSS transitions in 0fbbb07, and useToggleFade is gone. Measured on the iOS simulator with the main thread blocked as the toggle commits, two takes each. The CSS fade's first frame showed opacity 0.85 and 0.81, then about 170 ms of fade. The animator's showed 0.93 and then about 190 ms in one take, and jumped in one frame in the other. For this head, the body's iOS table gives how far the fade has run at the first presented frame.
| '@astryxdesign/core': patch | ||
| --- | ||
|
|
||
| [fix] The calendar in the DateInput and DateTimeInput bottom sheets now follows the iOS date picker's timing: |
There was a problem hiding this comment.
The new chevron glyph and turn, the fixed timing and the Reduce Motion behaviour change visual direction with no current visual authority behind them, so spec:AST-017 FR3 calls for [feat]. FR3 also asks the entry to name the old appearance: a down chevron that flipped up, and a toggle that finished in 0.01 s with Reduce Motion on.
There was a problem hiding this comment.
The body's Visual authority section records it: none is settled, and the chevron glyph is proposed, pending owner review (cixzhang).
| follows. | ||
| - **FR7 — Exits animate as UIKit's do.** A touch presentation MUST play the | ||
| exit its UIKit counterpart plays. **Proposed; pending owner review:** this | ||
| departs from the draft `spec:AST-090` FR1 (exits off by default) and FR10 |
c4eeaa3 to
0fbbb07
Compare
0fbbb07 to
09bc4ee
Compare
…es off, as the touch column does
The touch column's options lie under its drawn rows, so the proof taps the PM row's place on the screen, where the column's tap recognizer takes it, rather than asking for a tap on the option element.
…nto uikit/c21-wheel-proofs
…nto uikit/c21-wheel-listbox
…nto uikit/c21-wheel-short-loop
…nto uikit/c21-wheel-rest-and-spin
…o their own changesets In the same release meta#8179's time columns loop, so "no shipped column loops yet" would contradict it; the columns that loop say so themselves.
…heirs) into uikit/c21-wheel-rest-and-spin
… while the toggle fades The header's arrows and Reset, and DateInput's footer actions, sit outside the shield that covers the panels during the month/year cross-fade, and their `inert` followed the panels' (deferred to the fade's end). During the opening fade a tap on Done fell through the still-inert Done to Save beneath it and closed the DateInput sheet, and DateTimeInput's fading arrows and Reset still paged the month or cleared the pick. These few controls now leave with the toggle and arrive with the fade's end; only the panels' own `inert` waits for the fade, since flipping it restyles a panel's whole subtree.
… the glyph is Under Reduce Motion on a touch screen, a second title tap within the 200 ms dip restarted it from opacity 1, flashing the chevron back to opaque. The new dip now starts from the running dip's presented opacity, read before it is cancelled (a style read only in that case).
…llows the toggle during render `useFadeInert` mirrored the toggle into state from a layout effect when the swap is not deferred, costing a second commit per toggle (architecture:react-component-runtime INV1, INV3). `settled` now follows `isWheelOpen` during render in that case; the effect keeps only the branch where the committed panel shows no exit can run (no Web Animations), with a reason naming that read.
…fect synchronizes with The effect waits on the browser's clock and idle time (a timer for the sheet's present motion, then an idle callback), and its cleanup cools the wheels for the next opening (architecture:react-component-runtime INV3).
…ged, and where it was measured The panels' `inert` swaps when the fade ends (not a frame later), the commit's restyle is described without claiming it changes no inherited style, the old chevron and the 0.01 s fade are DateInput's, and the iPhone and Android claims are narrowed to the iOS simulator measurement.
…s own spin meta#8527's `spinTo` no longer takes a duration or a curve, so a column the time wheels move by themselves turns on the wheel's own spin: an animated `setContentOffset`, 0.3 s on Core Animation's ease-in-ease-out (`picker.tapSpin`, the role `timing.curves.move`), resolved under the column when the turn starts (spec:AST-094 FR4). TimeWheels no longer plays the literal `datePicker.wheels.columnTurn`, and the browser proof samples the AM/PM column's turn against that spin.
There was a problem hiding this comment.
Approval waits on an engineering owner's decision: no current record covers the title chevron that rests along the reading direction and turns a quarter turn down (spec:AST-094 leaves glyphs out of its scope), and the draft DateInput and DateTimeInput requirements this compare carries from its predecessors (component:DateInput FR13 with DEC-1, PR2 and AR8; component:DateTimeInput FR8) are unapproved. An engineering owner can provide or identify the governing spec, or record approval by commenting /approve-spec <full head SHA> on this pull request; the author may do so as an engineering owner. The toggle's 250 ms timing, the tapped day and Reduce Motion already follow current spec:AST-094 FR1, FR4 and FR8. Separately, these need changes before approval:
- Land the predecessors first: compared with
main, this pull request carries about 49,000 authored lines of the open stack. - The touch minute wheel now steps by
increment, which currentcomponent:TimeInputdefines as the typed field's arrow-key step; amend that row in its own pull request, or keep the sheet listing every minute. - Add real-device recordings for the iOS Safari and Android Chrome claims, as
spec:AST-094's platform support asks. - In the changeset, name DateTimeInput's old chevron (a down chevron that never moved) and narrow “nothing in the header or the footer takes a tap during the fade”, since a second tap on the title turns the fade around.
[Automated review]
|
|
||
| [feat] Under a finger, the calendar in the DateInput and DateTimeInput bottom sheets now follows the iOS date picker's timing: | ||
|
|
||
| - The month/year toggle cross-fades in 0.25 s on iOS's ease-in-out curve. It was DateInput's quick linear fade and DateTimeInput's instant swap. Once the sheet has settled, the hidden month/year wheels are laid out at opacity 0, and the panels swap `inert` when the fade ends, so the toggle's commit restyles little and, on the iOS 26.2 simulator, the fade is on screen from near its start. As in UIKit, nothing in the header or the footer takes a tap during the fade. |
There was a problem hiding this comment.
The title sits in the header, and a second tap on it mid-fade turns the fade around (the pull request's own browser proof does exactly that), so “nothing in the header or the footer takes a tap during the fade” overstates it. Naming what goes inert, the month arrows and Reset in the header and Save and Done in the footer, would match the code.
| [feat] Under a finger, the calendar in the DateInput and DateTimeInput bottom sheets now follows the iOS date picker's timing: | ||
|
|
||
| - The month/year toggle cross-fades in 0.25 s on iOS's ease-in-out curve. It was DateInput's quick linear fade and DateTimeInput's instant swap. Once the sheet has settled, the hidden month/year wheels are laid out at opacity 0, and the panels swap `inert` when the fade ends, so the toggle's commit restyles little and, on the iOS 26.2 simulator, the fade is on screen from near its start. As in UIKit, nothing in the header or the footer takes a tap during the fade. | ||
| - The title's chevron points along the reading direction and turns a quarter turn to point down while the wheels show. In DateInput it was a down chevron that flipped up. |
There was a problem hiding this comment.
This names DateInput's old chevron but not DateTimeInput's, which pointed down and never moved. spec:AST-017 FR3 asks a visual-direction entry to name the old and new appearance; adding “In DateTimeInput it was a down chevron that stayed still” would cover both sheets.
| time={parsedWheelTime} | ||
| hourFormat={hourFormat} | ||
| hasSeconds={hasSeconds} | ||
| minuteInterval={minuteIntervalOf(increment)} |
There was a problem hiding this comment.
The sheet's minute wheel now steps by increment, but the current component:TimeInput record's Increment row still reads “Arrow-key step.” with availability “Typed surface”. Amending that row (and DateTimeInput's timeIncrement docs) in the pull request that introduces this, or keeping the sheet listing every minute, would keep code and record in step.
…names what it synchronizes The un-keyed layout effect that lands a far jump synchronizes the pager's position with the DOM: it can move only once the render that mounts the target's pane has committed it, and moves before paint (architecture:react-component-runtime INV3).
There was a problem hiding this comment.
Approval waits on an engineering owner's decision: no current record covers the title chevron that rests along the reading direction and turns a quarter turn down, and the draft DateInput and DateTimeInput requirements this compare carries from its predecessors (component:DateInput FR13 with DEC-1, PR2 and AR8; component:DateTimeInput FR8) are unapproved. An engineering owner can identify the governing spec, or record approval by commenting /approve-spec <full head SHA> on this pull request; the author may do so as an engineering owner. The toggle's 250 ms timing, the tapped day and Reduce Motion already follow current spec:AST-094 FR1, FR4 and FR8. These still need changes before approval:
- Land the predecessors first: against
mainthis pull request carries about 49,000 authored lines of the open stack. - The touch minute wheel now steps by
increment, which currentcomponent:TimeInputdefines as the typed field's arrow-key step; amend that row in its own pull request, or keep the sheet listing every minute. - Add real-device recordings for the iOS Safari and Android Chrome claims, as
spec:AST-094's platform support asks. - In the changeset, name DateTimeInput's old chevron (a down chevron that never moved) and narrow “nothing in the header or the footer takes a tap during the fade”, since a second tap on the title turns the fade around.
[Automated review]
|
|
||
| [feat] Under a finger, the calendar in the DateInput and DateTimeInput bottom sheets now follows the iOS date picker's timing: | ||
|
|
||
| - The month/year toggle cross-fades in 0.25 s on iOS's ease-in-out curve. It was DateInput's quick linear fade and DateTimeInput's instant swap. Once the sheet has settled, the hidden month/year wheels are laid out at opacity 0, and the panels swap `inert` when the fade ends, so the toggle's commit restyles little and, on the iOS 26.2 simulator, the fade is on screen from near its start. As in UIKit, nothing in the header or the footer takes a tap during the fade. |
There was a problem hiding this comment.
The title sits in the header, and a second tap on it mid-fade turns the fade around (MonthYearToggle.interaction.browser.spec.ts:250-319 proves exactly that), so “nothing in the header or the footer takes a tap during the fade” is not what ships. Say that the header's month arrows and Reset and the footer's Save and Done take no tap during the fade.
| [feat] Under a finger, the calendar in the DateInput and DateTimeInput bottom sheets now follows the iOS date picker's timing: | ||
|
|
||
| - The month/year toggle cross-fades in 0.25 s on iOS's ease-in-out curve. It was DateInput's quick linear fade and DateTimeInput's instant swap. Once the sheet has settled, the hidden month/year wheels are laid out at opacity 0, and the panels swap `inert` when the fade ends, so the toggle's commit restyles little and, on the iOS 26.2 simulator, the fade is on screen from near its start. As in UIKit, nothing in the header or the footer takes a tap during the fade. | ||
| - The title's chevron points along the reading direction and turns a quarter turn to point down while the wheels show. In DateInput it was a down chevron that flipped up. |
There was a problem hiding this comment.
This names DateInput's old chevron but not DateTimeInput's, which pointed down and never moved. spec:AST-017 FR3 asks a visual-direction entry to name the old and new appearance, so add DateTimeInput's.
| time={parsedWheelTime} | ||
| hourFormat={hourFormat} | ||
| hasSeconds={hasSeconds} | ||
| minuteInterval={minuteIntervalOf(increment)} |
There was a problem hiding this comment.
The sheet's minute wheel now steps by increment, but current component:TimeInput's Increment row still reads “Arrow-key step.” with availability “Typed surface”, and the record is unchanged here; TouchDateTimeField.tsx:1439 does the same with timeIncrement. Amend the row (and DateTimeInput's timeIncrement docs) in the pull request that introduces this step, or keep the sheet listing every minute.
Depends on #8200. Review only this PR's change: vjeux/astryx@693fafc...c4d5c04
User impact
Under a finger, the month/year toggle runs off UIDatePicker's clock: DateInput fades linearly with a 180° flip, DateTimeInput swaps at once, a tapped day eases in. Now, from #8178's values: a 0.25 s ease-in-ease-out cross-fade, a chevron along the reading direction turning a quarter, a day selecting at once; hidden wheels laid out ahead. A mouse keeps today's toggle.
Before and after
Recorded on the iOS 26.2 simulator and the Android emulator (Chromium 158) from these heads; Overlays: JS clock, Reduce Motion, finger. No real device was available to the test rig. Before: #8200.
The fade on iOS. Mobile Safari clocks a transition from the style change, so the commit flips no inherited property on the panels: their
inertswaps when the fade ends;aria-hiddenand focus move with the toggle; a shield takes touches meanwhile, and the header's and footer's few controls leave with the toggle. Opening progress at the first frame:On Android (emulator, one take each) the opening drops one frame before (85 ms), none here. Commit script (earlier head): 24.5 ms at 4× CPU (was 27.5).
Visual authority
DDrow reused or amended.Design decisionstable by a team design owner.docs/design/.None is settled; the timing is UIKit's, played through internal motion roles
timing.stateChangeMsandtiming.curves.move(spec:AST-094FR1, FR4). Pending owner review (cixzhang): the chevron glyph.State matrix
design:reduced-motion): under a finger, a 200 ms cross-fade and chevron dip; with a mouse, at once.analyze-pr.js), import gzip, base → head: DateInput 148.8 → 150.2 KB, DateTimeInput 161.6 → 163.0 KB, PowerSearch 215.6 → 217.0 KB; component CSS +332 to +444 B.Scope
Testing
timing.stateChangeMsthrough its variable, besidetiming.curves.move;DateInputTouch.test.tsxholds the table's fade equal to the role and checks both variables.useChevronDip.test.tsx: a second change within the dip cancels the running one and starts from the glyph's current opacity, and the unmount cancels it; all failed before. The dip plays on the policy's fixed curve, so its middle stays on the turn's delay.SHEET_SETTLE_MSis a constant pinned tosprings.sheetPresentbyuseWheelsWarmUp.test.tsx, so the pickers ship none of the springs table.MonthYearToggle.interaction.browser.spec.ts: nothing outside the panels takes a tap while the toggle fades. With the fades stretched to 2 s, a real tap mid-fade on Done closed the DateInput sheet through Save beneath it (Chromium and WebKit), and a tap on DateTimeInput's next-month arrow reached it (WebKit); both now reach nothing.MonthYearToggle.interaction.browser.spec.ts, Chromium and WebKit, twice over in the top-head gate. Each test opens the sheet and waits for the hidden wheels' warm-up and its end before its first tap, so the only animation on the panel is the one the test starts (a CI run tapped during the warm-up's own transition, and the busy-thread block began before the click was handled); the busy-thread case, which WebKit skips, failed 4 of 10 in Chromium pinned to two cores at 4 workers (the compositor itself presented a frame only every 48 to 95 ms there), a load-sensitive proof still to be fixed at its cause. The spec checks:cubic-bezier(0.42, 0, 0.58, 1), which WebKit reports asease-in-out), opacity 0 → 1 androtate(-90deg)→rotate(0deg), DateTimeInput's too;DateInputTouch.test.tsx: the fades' and the chevron's definitions under the touch key and the two reduced-motion keys, spelled as the resolver's constants.aria-hidden(computedpointer-eventsstaysauto); a touch one frame into the fade meets the shield; the panels swapinertwhen the outgoing panel's exit has ended (faded to 0, or hidden at the cover's end), at least the fade's 250 ms after the commit on the document timeline, the wheels fully faded in. It failed on the previous head (inertat opacity 1, one frame after the commit). As a diagnostic (Chromium, 4× CPU), the commit restyles 36–41 elements instead of 574 in DateInput, and 75 instead of 1,023 in DateTimeInput.MonthYearToggle78/78 (6 skipped) over 6 runs in WebKit and 42/42 over 3 runs in Chromium.DateInputTouch.test.tsx: the toggle re-renders no Button or IconButton and the wheels once (as they go live); it failed before (6 button renders). Under a finger the calendar stays visible beneath the opaque wheels (aria-hiddenandinertkeep it out of reach), so closing flips no inheritedvisibility; theinertswap follows the fade's end event.useFadeInert.test.tsx:inertlands on the exit'stransitionendortransitioncancel(not another property's), at once when no exit runs, and with a mouse in the toggle's own commit (one commit per toggle); focus inside the outgoing panel moves to the incoming one, which goes live for it; focus outside stays.pnpm buildthen the rootpnpm typecheck;CI=true pnpm lint; the full core suite at 16 workers, 15,518 of 15,520 (the two Selector and MultiSelector bottom-sheet cases are test(Selector, MultiSelector): wait for the on-demand sheet module before the first open #8642's load red); the node project (its known reds, andtouch-support-bundle, which test(core): a touch component's import carries its gesture code, and nothing else does #8671 replaces: this head passes test(core): a touch component's import carries its gesture code, and nothing else does #8671's version, 8 of 8); interaction specs (MonthYearToggle, TimeWheels, MonthYearWheels, MonthScroller, MonthPager, WheelActivation) twice over: Chromium 93 of 94 (feat(Wheel): an owner's rest rule and turns from script for the picker wheel #8527's WheelActivation load red), WebKit 84 plus 10 skips.check:changesets.scripts/touch-support-bundle.test.mjs"is absent from the root entry" fails for every touch component under main's current test; test(core): a touch component's import carries its gesture code, and nothing else does #8671 replaces it with the per-component check, which lists DateInput, DateTimeInput, PowerSearch and TimeInput.Stack (merge in this order): … → #8178 → #8179 → #8146 → #8496 → #8200 → this PR (the full order is in #8156).