Repository navigation
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
github-actions
Bot
added
the
needs:design-review
|
AI review status for this pull request.
|
meta-cla
Bot
added
the
CLA Signed
![astracat-bot[bot]](https://avatars.githubusercontent.com/in/4796231?s=60&v=4){kind=small}
There was a problem hiding this comment.
The fix works as described: on this head no SegmentedControl segment moves or resizes when the selection changes, accessible names are unchanged, and the new width contract passes in CI. Approval waits on spec authority, because no current record covers segment geometry under selection (component:SegmentedControl is still a draft): an engineering owner needs to decide whether a selection should never move a segment, with every hug segment resting at its selected (semibold) width and so a few pixels wider than today. An engineering owner records that decision by commenting /approve-spec <full head SHA> on this pull request, and the author may do so if they are an engineering owner. Once it is settled, label the changeset to match ([feat] under AST-017 FR3 unless the decision names an existing claim this restores), and consider mentioning that each label now appears twice in the DOM, so text-based test queries such as getByText('List') match two nodes.
[Automated review]
PR Analysis Report📚 Storybook Preview🧪 Sandbox PreviewNo new or modified components detected. Bundle Size SummaryGzip figures measure each package's entry file, not the code an import pulls in.
Accessibility AuditStatus: No accessibility violations detected. Visual Regression48 of 502 shot(s) changed. A change here is a question, not a failure: check whether the after is the
and 28 more. Generated by PR Enrichment workflow | Storybook | Sandbox | View full report |
…hanges The selected label is semibold and an unselected one medium, so a segment sized to its own label grew as it was selected and shrank as it was deselected (2.3 px for "Grid" on desktop, 2.7 px on a phone), shifting its neighbors. Each label now shares its grid cell with an aria-hidden twin at the selected weight, so a segment is always as wide as its selected label; the column can still shrink, so a capped control still truncates. A real-engine contract checks every segment's box across selections.
7c1e88f to
cae4fe5
Compare
…nders twice, and how wide the shift was per platform
There was a problem hiding this comment.
The fix works as described: on this revision no SegmentedControl segment moves or resizes when the selection changes, accessible names are unchanged, and the new width contract passes in CI. Approval waits on spec authority, because no current record covers segment geometry under selection (component:SegmentedControl is still a draft): an engineering owner needs to decide whether a selection should never move a segment, with every hug segment resting at its selected (semibold) width and so slightly wider than today, and records that decision by commenting /approve-spec <full head SHA> on this pull request; the author may do so if they are an engineering owner. Separately, please add the base-against-head size figures that the component size rules now require for a style change (architecture:component-style-authoring INV6, spec:AST-080 FR8): the gzip size of astryx.css, SegmentedControl's gzip CSS delta, and the gzip JavaScript its import pulls in. Once the behavior is settled, tag the changeset to match ([feat] under spec:AST-017 FR3 unless the decision names an existing claim this restores).
[Automated review]
| '@astryxdesign/core': patch | ||
| --- | ||
|
|
||
| [fix] SegmentedControl segments keep their width when the selection changes. The selected label is heavier, so a segment sized to its own label grew as it was selected and shrank as it was deselected (about 2–3 px in a content-sized control), shifting its neighbors. Each label now reserves its selected width. |
There was a problem hiding this comment.
spec:AST-017 FR3 tags a visual change [fix] when it restores current visual authority and [feat] when it intentionally changes visual direction. No current record covers segment geometry under selection, so this reads [feat] unless the owner decision names an existing claim this restores.
There was a problem hiding this comment.
The change works as described: on this revision no SegmentedControl segment moves or resizes when the selection changes, and accessible names are unchanged. Approval waits on spec authority, because no current record covers segment geometry under selection (component:SegmentedControl is still a draft): an engineering owner needs to decide whether a selection should never move a segment, with every hug segment resting at its selected (semibold) width and so slightly wider than today, and records that decision by commenting /approve-spec <full head SHA> on this pull request; the author may do so if they are an engineering owner. Separately, please add the base-against-head size figures that the component size rules require for a style change (architecture:component-style-authoring INV6, spec:AST-080 FR8): the gzip size of astryx.css, SegmentedControl's gzip CSS delta, and the gzip JavaScript its import pulls in. Once the behavior is settled, tag the changeset to match ([feat] under spec:AST-017 FR3 unless the decision names an existing claim this restores).
[Automated review]
|
Withdrawn: the width twin is a hidden measurement element, which #8300 rules out; without it the selected-weight shift stays ≤ 0.8 pt on iOS and ≤ 0.4 px on Android. |
User impact
In a content-sized SegmentedControl (the default
huglayout), each segment is as wide as its label at its current weight (semibold when selected, medium otherwise), so a selection can move the segments, by an amount that depends on the font:After this change no segment moves or resizes with any font.
Evidence
SegmentedWidth.a11y.chromium.spec.tsfails on main ("Grid" 52.78 → 50.45 px on desktop, 56.89 → 54.23 px on a phone).Problem and solution fit
hugsegment, and the weight changes the box.Expected behavior and authority
component:SegmentedControl(draft) FR4: selected, unselected and disabled items keep the same anatomy, with selection reflected as state onsegmented-control-item.Smallest restoration
SegmentedControlItem: the label sits in a one-cell grid with an aria-hidden twin at the selected weight. The cell is always the selected width, and the column still shrinks, so a capped control still truncates.getByText('Grid')) matches two nodes. The changeset says to find segments by role and name.hug, an unselected segment is now as wide as when selected (up to 3 px wider where the weight is synthesized);fillwas already equal width.Scope
Testing
pnpm vitest run packages/core/src/SegmentedControl packages/core/src/RadioList/__tests__/RadioGroup.a11y.test.tsx: passes, including a check that the twin is hidden from assistive technology. The existing truncation tests now read the visible title.pnpm exec playwright test packages/core/src/SegmentedControl/__tests__/SegmentedWidth.a11y.chromium.spec.ts --project chromium: desktop (1024 × 768, mouse) and phone (402 × 714 at 3×, touch). 2 passed; both fail on main.pnpm -F @astryxdesign/core typecheck,pnpm check:changesets, eslint and prettier on touched files.