Repository navigation
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
meta-cla
Bot
added
the
CLA Signed
github-actions
Bot
added
the
needs:design-review
|
AI review status for this pull request.
|
PR Analysis Report📚 Storybook Preview🧪 Sandbox PreviewModified ComponentsSlider (@astryxdesign/core) · View in Storybook
Tooltip (@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. Bundle Size SummaryGzip figures measure each package's entry file, not the code an import pulls in.
Accessibility AuditStatus: 1 accessibility violation(s) found — 1 serious. Tooltip - 1 issue(s)
Visual Regression55 of 504 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.
Requesting changes: page-level LTR, RTL and vertical sliders render the same as main in Chromium, but two problems need fixing before this lands.
- Inside a
dir="ltr"region of an RTL page, the newtranslateflips on any[dir="rtl"]ancestor whileinset-inline-start: 0and the keyboard follow the region, so the thumbs paint outside the control and ArrowRight moves them left; keying the flip on the element's own direction with':dir(rtl)', which StyleX lowers as-is, fixes it. - The #5050 inset tests were replaced by checks on the private progress properties, and with the half-thumb inset removed from the thumb's CSS all 76 Slider tests still pass, so please add a real-browser check of the thumb and fill positions at min, mid and max.
- The changeset and file header say a value change never lays out, which holds only for
valueDisplay="none"; with the default tooltip or the text display a drag still lays out on every value change.
[Automated review]
| // marks. `translate` is physical, so it flips its sign under RTL. | ||
| translate: { | ||
| default: `calc(var(${THUMB_PROGRESS}) * (100cqi - ${THUMB_SIZE}px)) 0`, | ||
| ':is([dir="rtl"] *)': `calc(var(${THUMB_PROGRESS}) * (${THUMB_SIZE}px - 100cqi)) 0`, |
There was a problem hiding this comment.
This flip matches whenever any ancestor has dir="rtl", but the start edge (insetInlineStart: 0, line 369) and the keys (isRtlElement) follow the element's own direction. In a dir="ltr" region of an RTL page the thumb starts at the left edge and travels left: at 75 it paints 275 px outside the control, and ArrowRight moves it further left. A ':dir(rtl)' condition here and at lines 307, 331 and 342 keys the flip on the element's own direction; StyleX lowers it to a plain :dir(rtl) rule.
There was a problem hiding this comment.
A thumb in an LTR region of an RTL page has to travel the way its own keys and start edge do. Fixed in 986fddd (rebased from a03c859): every translate flip now keys on :dir(rtl), the element's own direction. SliderGeometry.a11y.chromium.spec.ts covers both mixed-direction regions; with the ancestor-keyed flip, its two LTR-region-of-an-RTL-page cases fail.
| ])( | ||
| 'insets a vertical thumb at value $value so it stays in bounds', | ||
| ({value, position}) => { | ||
| 'places the thumb by its progress at value $value, horizontal and vertical', |
There was a problem hiding this comment.
These assertions read --_slider-progress, which is percent / 100 and carries no inset, so they replace the #5050 tests without covering them: with the half-thumb inset removed from the thumb's CSS travel, all 76 tests in this file still pass, while the same regression fails 6 on main. A Chromium test asserting the thumb box inside the control at min and max, and the thumb centre at the fill's end mid-range, would keep #5050 protected.
There was a problem hiding this comment.
The #5050 inset needs a real-browser guard, since jsdom computes neither container units nor translate. Fixed in 986fddd (rebased from a03c859): SliderGeometry.a11y.chromium.spec.ts runs in CI and checks the thumbs inside the control at min and max, and the thumb centre at the fill's end mid-range, for single and range sliders in LTR, RTL and both mixed-direction regions.
| '@astryxdesign/core': patch | ||
| --- | ||
|
|
||
| [perf] Slider: the thumbs and the filled range move by `translate` in the control's container units instead of by inset and width, so dragging or stepping a slider no longer lays out the page on every value change. Rendering is unchanged. |
There was a problem hiding this comment.
This holds only for valueDisplay="none": in Chromium a 60-move drag of the default slider (value tooltip) lays out 30 times both before and after this change, and the text display 15 times both ways. Suggest scoping it to the parts that moved, for example "…so the thumbs and the filled range no longer lay out on every value change; a displayed value still does." The @output header (Slider.tsx line 8) and the THUMB_PROGRESS comment (line 169) say the same.
There was a problem hiding this comment.
The claim should match what a drag actually costs. Fixed in 986fddd (rebased from a03c859): the changeset, the @output header and the THUMB_PROGRESS comment now say that moving the thumbs and the fill never lays out, while a value tooltip or text display still does as its text changes. The PR title and description say the same now.
…hange never lays out The thumb and the filled range were placed with inset-inline-start/bottom and width/height, so every value change during a drag laid out the page (51 layouts over 60 mouse moves). They now travel by translate, computed in CSS from a progress custom property against the control's container units (container-type: size): the server still renders the right place, RTL and vertical keep their geometry, and a value change only restyles. The filled range is a full-length bar translated inside the track's clip, so it moves the same way.
…wser geometry contract; narrow the layout claim
a03c859 to
986fddd
Compare
vjeux
changed the title
There was a problem hiding this comment.
Requesting changes: the translate-based travel renders like main in Chromium (LTR, RTL, range, marks and vertical), keeps the value tooltip on the thumb in Chromium and WebKit, fixes the thumb inside an LTR region of an RTL page, and saves the layouts the changeset now describes for valueDisplay="none". One gap remains: the vertical #5050 position test now reads only --_slider-progress and the new geometry spec mounts only horizontal stories, so removing the half-thumb inset from thumbVertical leaves every Slider test passing. Please add a vertical case (for example core-slider--vertical-orientation) to SliderGeometry.a11y.chromium.spec.ts that checks the thumb inside the control at Home and End and the fill ending at the thumb's centre.
- Not blocking: on a control padded through
controlStyleorcontrolXstyle,100cqimeasures the content box while the thumb starts at the padding edge, so the thumb lands twice the padding short of the last mark and "Rendering is unchanged" in the changeset does not hold there.
[Automated review]
| />, | ||
| ); | ||
| expect(screen.getByRole('slider')).toHaveStyle({bottom: position}); | ||
| expect(progressOf(screen.getByRole('slider'))).toBe(progress); |
There was a problem hiding this comment.
This vertical check reads --_slider-progress, which carries no inset, and SliderGeometry.a11y.chromium.spec.ts mounts only horizontal stories, so nothing replaces the #5050 vertical inset test it took over: with (0px - 100cqb) in thumbVertical (Slider.tsx:383) all 98 Slider tests still pass. A vertical case in the geometry spec (thumb inside the control at Home and End, fill ending at the thumb's centre) would restore it.
There was a problem hiding this comment.
Covered by 98ada67 (Cindy Zhang's commit): SliderGeometry.a11y.chromium.spec.ts mounts the vertical story and checks that the thumb stays inside the control and the fill follows the value. With (0px - 100cqb) in thumbVertical it fails (the thumb is 20 px out, against a limit of 1 px).
…ayed A real-browser trace of the claim the layout counters showed by hand: 59 mouse moves of a dragged thumb (valueDisplay none) add no Layout to Chromium's performance counters. The same test on main counts 10.
There was a problem hiding this comment.
Requesting changes: the translate-based travel renders like main in Chromium (LTR, RTL, range, marks, vertical and the value tooltip), fixes the thumb inside an LTR region of an RTL page, and the drag the new test performs lays out 0 times with valueDisplay="none" where main lays out 10. One gap from the earlier review remains: the vertical #5050 test now reads only --_slider-progress and SliderGeometry.a11y.chromium.spec.ts mounts only horizontal stories, so removing the half-thumb inset from thumbVertical still leaves every Slider test passing. Please add a vertical case (for example core-slider--vertical-orientation) that checks the thumb inside the control's top and bottom edges at Home and End and the fill ending at the thumb's centre.
- Not blocking: on a control padded through
controlStyle,controlXstyleor a theme rule,100cqimeasures the content box while the thumb starts at the padding edge, so the thumb lands twice the padding short of the last mark and of the fill's end.
[Automated review]
| test(`a single slider's thumb and fill follow its value: ${region.name}`, async ({ | ||
| page, | ||
| }) => { | ||
| await mount(page, 'core-slider--default', region.page, region.region); |
There was a problem hiding this comment.
Every case in this spec mounts a horizontal story (here, line 162 and line 190) and measure() reads only left and right edges, so nothing replaces the vertical #5050 test: with (0px - 100cqb) in thumbVertical (Slider.tsx line 383) all 98 Slider tests still pass. A core-slider--vertical-orientation case that checks the thumb inside the control's top and bottom edges at Home and End, and the fill ending at the thumb's centre, would restore it.
There was a problem hiding this comment.
…fari) Recordings of the iOS 26.2 simulator (iPhone 17 Pro) in Mobile Safari, cropped to the page; the gray dot is the finger, drawn by the test page. main against each pull request: meta#8151 coincident range thumbs, meta#8168 translate travel, meta#8190 the touch presentation and its held-thumb fix.
On main a Slider in a left-to-right region of a right-to-left page draws its thumb one thumb width past its value (its centering transform flips on any RTL ancestor); the travel here flips on the element's own direction, so the changeset no longer says rendering is unchanged without that exception.
There was a problem hiding this comment.
Requesting changes for one small fix. The translate-based travel keeps Slider's geometry in Chromium and Firefox, puts the thumb on its value in an LTR region of an RTL page, centres the value tooltip on its thumb in Firefox, and takes a valueDisplay="none" drag from 10 layouts to 0. SliderValueTooltip now sits between Slider's doc comment and export function Slider (Slider.tsx:574-628), so the comment no longer attaches to Slider: its emitted declaration loses the description and example, and the Storybook docs page loses its introduction; moving SliderValueTooltip above that comment, or below Slider, fixes it.
[Automated review]
| * <Slider label="Price range" value={[20, 80]} onChange={setRange} /> | ||
| * ``` | ||
| */ | ||
| /** |
There was a problem hiding this comment.
Slider's doc comment (lines 574-582) now leads this function instead of export function Slider (line 628), so it attaches to nothing: the declaration emitted for Slider loses its summary and @example, and Storybook's docgen description for Slider is empty. Moving SliderValueTooltip with its comment above line 574, or below Slider, puts the comment back on the component.
There was a problem hiding this comment.
Fixed in 1cb400e: SliderValueTooltip now sits above the Component section, so the doc comment is directly above export function Slider again. The build's tsc now emits the summary and the @example above export declare function Slider; on the previous head there was no comment there. A new case, SliderDocComment.test.ts, parses Slider.tsx and checks that the last JSDoc block above the component carries the summary and an @example. It fails on the previous head.
SliderValueTooltip was declared between Slider's doc comment and `export function Slider`, so the comment attached to the helper: the declaration emitted for Slider lost its summary and example (checked with the build's tsc), and the Storybook docs page lost its introduction. The helper now sits above the Component section. A case parses Slider.tsx and checks that the last JSDoc block above `export function Slider` carries the summary and an `@example`; it fails on the previous head.
There was a problem hiding this comment.
Recommending approval: the translate-based travel keeps Slider's geometry in Chromium and Firefox, puts the thumb on its value in an LTR region of an RTL page, centres the value tooltip on its thumb in Firefox, and takes a valueDisplay="none" drag from 10 layouts to 0. Slider's doc comment sits on export function Slider again, and SliderDocComment.test.ts now guards it. The red pr-a11y job fails only a DateInput wheel-scroll case this change does not touch, while its Slider geometry step passes, so a rerun of that job is the only follow-up.
[Automated review]
…x and moves by the thumb's translate Engines disagree on whether CSS anchor positioning follows a `translate` on the anchor: Chromium anchors to the moved box, Firefox to the layout box. Instead of a thumb-sized anchor that layout places at the value (an extra element per thumb, laid out on every value change), the value tooltip now anchors to the travel box, which no transform moves, so every engine resolves the same anchor, and it moves by the same `translate` as its thumb, from the same progress, so there is no double translation: - Horizontal: the tooltip starts at the travel's start edge and travels by the thumb's progress in container units, mirrored under :dir(rtl). - Vertical: it starts at the travel's bottom and travels up; the travel box is as wide as the field, so a negative inline margin pulls it in beside the centred thumb, which the inline flip mirrors with the side. - Both clamp to the travel box, so a label wider than the thumb shifts inward at the ends instead of leaving the control, and only the placement-axis flip is kept (an alignment fallback would move the edge the translate starts from). useTooltip's renderTooltip now applies the `xstyle` and `style` its second argument already accepted, which carries the translate. A new browser spec runs in Chromium, Firefox and WebKit in CI: the tooltip is centred on the thumb at 10/25/50/75/90, over the thumb and inside the control at both ends, flipped below with no room above, RTL, vertical, both thumbs of a range, forced colors and reduced motion, with screenshots and a drag clip per engine uploaded as evidence. The geometry spec's anchor-box checks move there.
|
The new Commit 9f0aadb (branch
This head's |
There was a problem hiding this comment.
Requesting changes: the translate-based thumb and fill travel keeps Slider's geometry in Chromium and Firefox and puts the thumb on its value in an LTR region of an RTL page, but the newest commit's value-tooltip placement regresses. Please place the value tooltip with geometry that does not depend on where its layer is hosted (the previous revision's layout-placed anchor box under the layer's own anchor-mode placement worked), and add tooltip cases for a Slider inside a list or table cell and for mixed-direction regions.
- Inside a
ul > lior a table cell, the tooltip renders 380–388 px from its thumb in Chromium and Firefox, because100cqistops measuring the track once the layer is portaled out of the slider. - In Firefox, an RTL region on an LTR page (or the reverse) puts the tooltip off-screen, for example at x −592 for a thumb at 640.
- Passing
positionTryFallbacksthroughrenderTooltip'sstyleconflicts withspec:AST-059FR4, and keeping the travel box element in React state conflicts witharchitecture:react-component-runtimeINV1.
[Automated review]
| // keeps it in the viewport wherever the slider is. | ||
| valueTooltipHorizontal: { | ||
| translate: { | ||
| default: `clamp(0px, ${THUMB_INSET_PX}px + var(${TOOLTIP_PROGRESS}) * (100cqi - ${THUMB_SIZE}px) - 50%, 100cqi - 100%) 0`, |
There was a problem hiding this comment.
100cqi here measures the travel box only while the tooltip is hosted inside it. When the Slider sits in a ul, table, label, span, link or button, useLayer portals the tooltip outside that ancestor and the units resolve against another container or the viewport: in a table cell at 50 the tooltip lands at 784 px against a thumb at 396 px, in Chromium and Firefox. Anchoring to a box that layout places at the value, as the previous revision did, keeps the placement independent of hosting.
| // Only the placement-axis flip: the translate already keeps the tooltip | ||
| // inside the control on the other axis, and an alignment fallback would | ||
| // move the edge the translate starts from. | ||
| positionTryFallbacks: isHorizontal ? 'flip-block' : 'flip-inline', |
There was a problem hiding this comment.
spec:AST-059 FR4: “The runtime authors this order; a component passes no fallbacks of its own to an anchor-mode layer.” renderTooltip keeps anchor mode, so this override, together with the self-authored translate geometry, takes over placement the runtime owns (architecture:layer-runtime INV3).
| const trackRef = useRef<HTMLDivElement>(null); | ||
| const draggingThumbRef = useRef<number | null>(null); | ||
| // The travel box: every part sits in it, and the value tooltips anchor to it. | ||
| const [travelBox, setTravelBox] = useState<HTMLDivElement | null>(null); |
There was a problem hiding this comment.
architecture:react-component-runtime INV1: “DOM nodes and whole DOM collections MUST NOT be stored in React state.” This also gives every Slider a second render on mount and needs the layout effect in SliderValueTooltip, which names no external system (INV3). A callback ref that attaches the tooltip anchor, as the previous revision's ref={tooltip.positionRef} did, avoids both.
| ); | ||
| await page.locator('.astryx-slider-control').first().waitFor(); | ||
| await page.evaluate(dir => { | ||
| document.documentElement.dir = dir; |
There was a problem hiding this comment.
Setting the page direction to the slider's own means no mixed-direction case runs. In Firefox an RTL region of an LTR page puts the tooltip at x −592 for a thumb at 640, and an LTR region of an RTL page at 2432 in a 1280 px viewport; the geometry spec's four REGIONS would catch it here.
|
The review's suggested fix would bring back the layout-placed anchor box that 5863937 removed on purpose, so there are two ways forward:
Either one will be implemented once chosen, with tooltip cases for a list item, a table cell and mixed-direction regions. |
# Conflicts: # .github/workflows/ci.yml
|
Re-asking once on the tooltip placement, since it's the open choice here:
My pick is (b): it places the tooltip correctly in lists, table cells, labels and mixed-direction regions. #8190 carries (b) today, so if you pick (a), #8190 re-merges this PR's final head before it merges. |
# Conflicts: # .github/workflows/ci.yml
# Conflicts: # .github/workflows/ci.yml
# Conflicts: # .github/workflows/ci.yml
|
An offer for this PR's conflict with It folds |
The workflow is main's: since meta#8367 pr-a11y discovers browser specs and ci-test-routing.test.mjs forbids naming one in a step, so the Slider steps this branch added go; its Slider specs run through discovery.
There was a problem hiding this comment.
Approval waits on an engineering owner's decision about one addition. useTooltip's renderTooltip now applies a caller's xstyle and style, and no current spec governs that hook. An engineering owner (the author may decide, as one) needs to approve it and name its governing record, or rule it out, by commenting /approve-spec <full head SHA> on this pull request. Whatever that decision, these need fixing:
- In a list, table,
label, link,buttonorspan, the value tooltip is portaled out of the travel box, so its100cqistops measuring the track and a 500 px Slider shows it 406 px from its thumb at 50; anchoring it to a box that layout places at the value, under the layer's own anchor mode, also removes the component-authoredpositionTryFallbacksthatspec:AST-059FR4 forbids and the travel box held in React state. test.use({video})insidedescribe('drag clip')makesplaywright test --listfail, sopr-a11y (browser specs)runs no spec; it needs file or project scope.- The changeset's claim that the tooltip sits over the thumb in every engine needs correcting with the fix.
[Automated review]
| // keeps it in the viewport wherever the slider is. | ||
| valueTooltipHorizontal: { | ||
| translate: { | ||
| default: `clamp(0px, ${THUMB_INSET_PX}px + var(${TOOLTIP_PROGRESS}) * (100cqi - ${THUMB_SIZE}px) - 50%, 100cqi - 100%) 0`, |
There was a problem hiding this comment.
100cqi measures the travel box only while the tooltip is its descendant. layerHost.ts portals the layer beyond an unsafe ancestor such as ul, ol, table, label, a, button or span, and there 100cqi resolves against another container or the small viewport. On this head's Storybook build, a 500 px Slider in a list item or table cell shows its tooltip 406 px from the thumb at 50 and 802 px at 100. Anchoring to a box that layout places at the value keeps the placement independent of hosting.
| // Only the placement-axis flip: the translate already keeps the tooltip | ||
| // inside the control on the other axis, and an alignment fallback would | ||
| // move the edge the translate starts from. | ||
| positionTryFallbacks: isHorizontal ? 'flip-block' : 'flip-inline', |
There was a problem hiding this comment.
spec:AST-059 FR4: "The runtime authors both orders; a component passes no fallbacks of its own to an anchor-mode layer." useLayer spreads this style after its own positionTryFallbacks (var(<try-fallbacks property>, <standard list>)). This value therefore replaces both the standard order and the anchor-clear switch for every value tooltip.
| const trackRef = useRef<HTMLDivElement>(null); | ||
| const draggingThumbRef = useRef<number | null>(null); | ||
| // The travel box: every part sits in it, and the value tooltips anchor to it. | ||
| const [travelBox, setTravelBox] = useState<HTMLDivElement | null>(null); |
There was a problem hiding this comment.
architecture:react-component-runtime INV1: "DOM nodes and whole DOM collections MUST NOT be stored in React state." Holding the node here also renders every Slider twice on mount and needs the unnamed layout effect in SliderValueTooltip (INV3). A callback ref composed with positionRef avoids both.
| }); | ||
|
|
||
| test.describe('drag clip', () => { | ||
| test.use({video: {mode: 'on', size: {width: 800, height: 300}}}); |
There was a problem hiding this comment.
Playwright rejects this: "Cannot use({ video }) in a describe group, because it forces a new worker." On this head playwright test --list --project chromium exits 1, so pr-a11y (browser specs) ran no spec, this pull request's geometry spec included. Move video to file or project scope.
| '@astryxdesign/core': patch | ||
| --- | ||
|
|
||
| [perf] Slider: the thumbs and the filled range move by `translate` in the control's container units instead of by inset and width, so moving the thumbs and the fill no longer lays out the page; with `valueDisplay="none"` a drag or step lays out nothing at all (the value tooltip and text display still lay out as their text changes). Rendering is unchanged, except in a left-to-right region inside a right-to-left page, where the thumb now sits on its value instead of one thumb width past it, and at the ends of a vertical slider, where the value tooltip now stays within the control. The value tooltip anchors to the slider's untransformed travel box and moves by the same `translate` as its thumb, so it sits over the thumb in every engine (engines disagree on whether CSS anchor positioning follows a `translate` on the anchor) with no added element, and inline padding on the control still moves no part. `useTooltip`'s `renderTooltip` now applies the `xstyle` and `style` its second argument already accepted. |
There was a problem hiding this comment.
"Sits over the thumb in every engine" and "Rendering is unchanged" do not hold where the layer is portaled, such as a list, table, label, link, button or span. Please revise with the tooltip fix.
Rebased on #8152 (merged). #8151 and #7516 change the pointer handlers, not these styles; #8190's touch presentation builds on this.
Maintainer impact
Every value change moves the thumb and the fill through
inset-inline-start/bottomandwidth/height, so a drag lays out the page on each move: main-thread time in every frame, and nothing a compositor animation could drive.Evidence
iOS 26.2 simulator, Mobile Safari; each pair is
mainover this branch, and the gray dot is the finger.valueDisplay="none").SliderGeometry.a11y.chromium.spec.tsnow asserts it (10 layouts onmain).mainwithin 0.013 px in Chromium and the iOS simulator; screenshots differ only in antialiasing.Intended invariant
insetPositionputs them (the half-thumb inset from [Bug] Slider thumb overhangs the component bounds at min and max #5050).maindraws the thumb 20 px past its value (its centering flips on any RTL ancestor); here the travel flips on the element's own direction.component:SliderFR1–FR3: same parts and targets; the filled range stays untargeted.Change
container-type: size) filling the control's padding box, so padding moves none.translateagainst100cqi/100cqb, flipped under:dir(rtl), as its inline start and its keys are.Scope
Testing
pnpm exec vitest run --project ui packages/core/src/Slider: 98 tests pass. The position tests check the published progress (jsdom computes neither container units nortranslate), and a test covers the fill's ends in single and range mode.pnpm exec playwright test packages/core/src/Slider/__tests__/SliderGeometry.a11y.chromium.spec.ts --project chromium: 8 pass. With the earlier ancestor-keyed flip, the two LTR-region-of-an-RTL-page cases fail.main's build, and the layout counters.main's build.build:cssof core, thenpnpm exec vitest run --project node scripts/build-css.test.mjs: 11 tests pass.pnpm -F @astryxdesign/core typecheck, eslint and prettier on the touched files,pnpm check:changesets, and the pre-commit checks.mainafter fix(Slider): a drag belongs to the pointer that started it #8152 (the header lines and the CI step list merged by hand): the Slider suite, the geometry spec, core typecheck, the build-css test and the comparison againstmainwere re-run on the rebased head and pass;pnpm -F @astryxdesign/storybook typecheckreports the same errors asmain(unbuilt theme and chart packages, none in Slider).SliderGeometry.a11y.chromium.spec.tsasserts that 59 moves of a dragged thumb (valueDisplay="none") add no Layout to Chromium's counters; 9 pass, and onmain's build the new case counts 10.main's build against this branch's, 60 fps video cropped to the page.pnpm check:changesetsand prettier pass.translate), so in Mobile Safari it sat at the track's start (measured on the iOS 26.2 simulator: tooltip centre x 30 pt with the thumb at 201; now within 1 pt of the thumb through the drag, GIF above). It anchors to a thumb-sized box that layout places at the value. And padding on the control moved the parts off the track; they now sit in a box filling the control's padding box. Geometry cases (four regions, vertical; 12 px inline padding) fail on the previous head (anchor 10–24 px off). Slider, Tooltip and a11y slider suites 160 pass; geometry spec 16; a11y Chromium slider 19; build-css 11; core typecheck; strict eslint;check:changesets,check:sync; storybook typecheck reportsmain's 43 errors.SliderValueTooltipsat between Slider's doc comment andexport function Slider, so the emitted declaration lost its summary and@exampleand the Storybook docs page its introduction (checked with the build'stsc). The helper moves above the Component section (a 13-line move).SliderDocComment.test.tschecks that the last JSDoc above the component has the summary and an@example; it fails on the previous head. Slider suite 99; core typecheck; strict eslint.pr-a11yon 1cb400e failed one case outside Slider: DateInput'sWheelPinchZoom.a11y.chromium.spec.ts("one finger dragged up a wheel still scrolls it": scrollTop 1652, wanted > 1656). That spec's timing flake is fixed onmainby test(DateInput): the wheel pinch-zoom spec opens its minute wheel at a fixed time #8332 (merged 02:54Z, after this run's merge base). Every Slider case in the job passed. It clears at this PR's next real push.