Repository navigation
Conversation
…pressed treatment and thumb lift roles, drag-to-select (FR5–FR10, OQ1–OQ2)
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
AI review status for this pull request.
|
github-actions
Bot
added
the
spec-auto-merge
PR Analysis Report
The exact-head preview is not available yet. Generated by PR Enrichment workflow | View current CI run |
meta-cla
Bot
added
the
CLA Signed
|
Posted by Cindy's agent on her behalf. Cindy's decisions on SegmentedControl press feedback under a finger:
The SegmentedControl record states both, and this PR conforms: no thumb lift by default, and the overlay stays on press. |
…ed-thumb lift role, default none (DEC-1, user-states DR3)
…-touch-presentation
cixzhang
changed the title
|
/approve-spec 660cd7e |
![astracat-bot[bot]](https://avatars.githubusercontent.com/in/4796231?s=60&v=4){kind=small}
There was a problem hiding this comment.
SegmentedControl's touch presentation is owner-approved for this head, but the two records still contradict themselves and a current claim in a few places, so this needs changes before it lands. Please make FR10 commit the nearest enabled segment (and say what a cancelled touch does), carry the DR3 lift into the design:user-states matrix rows, example and decision log, and remove the first-draft leftovers: the open OQ2 and the dim role in the FR7/FR8 verification row.
- The compatibility section still says runtime and styling are unchanged, and nothing says how a theme's selected-segment styles (Neutral sets
boxShadow: 'none') reach the sliding::beforesurface. - FR6's Reduce Motion cross-fade needs a second surface that the FR5/FR6/PR1 row rules out, and FR10 cites
family:action-groups, which doesn't exist onmainyet.
[Automated review]
| | FR7 | Under a finger, a held unselected segment paints the pressed overlay on its part, as under a mouse (`design:user-states` DR1); no theme role changes or dims it. | `design:user-states` DR1; owner decision (DEC-1) | Decided | | ||
| | FR8 | Under a finger, holding the selected segment lifts the selected surface by the theme's general pressed-thumb-lift role for draggable thumbs (SegmentedControl, Switch, Slider), only while it is pressed; the role is none by default, so shipped themes are unchanged. A theme that sets it grows the surface and casts its shadow, as a transform and shadow on the existing surface (`design:user-states` DR3). | `design:user-states` DR3; owner decision (DEC-1) | Decided | | ||
| | FR9 | During a drag of the selected surface, the selected label's colour follows the surface, with an internal hysteresis around each boundary; label weights change only when the drag starts. A tap selects through the browser's click (`spec:AST-094` FR11). | Measured iOS 26.2 behavior; `spec:AST-094` FR11 | Follows `spec:AST-094` | | ||
| | FR10 | Under a finger, a drag from the selected segment carries the selected surface with the finger, within an internal overshoot past the end segments, and the lift commits the segment nearest the finger through that segment's click; a drag that starts on another segment leaves the surface in place and commits where it lifts, as a menu's press-tracking slide commits where it lifts (`spec:AST-094` FR26–FR28). | Measured iOS 26.2 behavior; this record's own model (`family:action-groups` exception) | Governed here | |
There was a problem hiding this comment.
FR10 commits "the segment nearest the finger", but a segment can be disabled on its own and its click selects nothing, while design:user-states DR2 keeps a disabled control inoperable. Could this say "the nearest enabled segment", add a disabled segment to the FR9/FR10 row, and say where the surface goes on a cancelled touch? The basis cell also cites family:action-groups, which doesn't exist on main yet.
| SegmentedControlItem children. This draft records the current consumer anatomy | ||
| and theming ownership without changing selection behavior, targets, or public | ||
| API. | ||
| and theming ownership, and proposes how a finger presses, drags, and selects |
There was a problem hiding this comment.
"proposes" narrates the change (rubric R1). The Compatibility section just below also still says runtime and styling are unchanged, although FR5–FR10 change both by default under a finger. Could both be restated, including how a theme's selected-segment styles (for example Neutral's selected: { boxShadow: 'none' }) reach the sliding surface?
| | FR1, FR2 | `SegmentedControl.test.tsx` radiogroup and rendering suites | Control with multiple segment items | Removing the group or item semantics fails existing role and content assertions. | `audit:SegmentedControl/anatomy` | | ||
| | FR3 | `SegmentedControl.test.tsx` label and icon suites | Visible label, icon with label, icon-only item | Removing or changing current label/icon rendering fails existing DOM assertions. | `audit:SegmentedControl/anatomy` | | ||
| | FR4 | `SegmentedControl.test.tsx` selection and disabled suites | Selected, unselected, and disabled items | Breaking reflected item state fails current ARIA, class, or data-attribute assertions. | `audit:SegmentedControl/theming` | | ||
| | FR5, FR6, PR1 | Selection-motion unit tests and real-browser proofs in Chromium and WebKit | a tap, a retarget, keyboard selection, Reduce Motion, a mouse | a second surface or added element, a Layout or Paint per frame, a curve off its role, travel under Reduce Motion, or changed behavior under a mouse fails | `audit:SegmentedControl/theming` | |
There was a problem hiding this comment.
FR6's Reduce Motion cross-fade shows the old and new surfaces together, but this row fails "a second surface" with Reduce Motion among its states, and PR1 names only ::before. Could the record name the cross-fade's second paint surface (for example the radiogroup's ::after) and exempt it here?
| | FR3 | `SegmentedControl.test.tsx` label and icon suites | Visible label, icon with label, icon-only item | Removing or changing current label/icon rendering fails existing DOM assertions. | `audit:SegmentedControl/anatomy` | | ||
| | FR4 | `SegmentedControl.test.tsx` selection and disabled suites | Selected, unselected, and disabled items | Breaking reflected item state fails current ARIA, class, or data-attribute assertions. | `audit:SegmentedControl/theming` | | ||
| | FR5, FR6, PR1 | Selection-motion unit tests and real-browser proofs in Chromium and WebKit | a tap, a retarget, keyboard selection, Reduce Motion, a mouse | a second surface or added element, a Layout or Paint per frame, a curve off its role, travel under Reduce Motion, or changed behavior under a mouse fails | `audit:SegmentedControl/theming` | | ||
| | FR7, FR8 | Theme tests and real-browser proofs under a finger | the default theme, a theme that sets a dim and a lift, a held unselected segment, a held selected segment | a look that ignores the theme roles, a lift or dim under the default theme, or a lift that adds an element fails | `audit:SegmentedControl/theming` | |
There was a problem hiding this comment.
This row still tests "a theme that sets a dim and a lift" and fails "a lift or dim under the default theme", but FR7 says no theme role dims a held segment and DEC-1 rejects the dim role. Suggest dropping the dim and failing any theme role that changes or dims a held unselected segment.
| - **OQ2 — A general pressed-thumb lift for draggable thumbs.** (`human-design`) | ||
| Open. Proposed: one theme role shared by SegmentedControl, Switch, and Slider, | ||
| none by default (today's look), amending `design:user-states` DR3 for touch | ||
| presentations. |
There was a problem hiding this comment.
OQ2 is still marked Open under "None.", though DEC-1 decides it and this PR already amends DR3, so the description's "R6 open questions: none" doesn't hold yet. Suggest deleting the bullet.
| receives the pressed overlay. A theme may own one press treatment on a | ||
| selected thumb: the general pressed-thumb lift shared by the draggable thumbs | ||
| of SegmentedControl, Switch, and Slider lifts a selected thumb only while it | ||
| is pressed, is none by default, and keeps a Switch thumb circular. Under a finger the item keeps that surface, and its press timing follows |
There was a problem hiding this comment.
DR3 now allows a theme lift, but the SegmentedControl matrix row ("keeps its raised surface unchanged", under "This table is the complete current claim"), the example, and DEC-1 still say the held selected segment never changes, and the Switch and Slider rows don't mention the lift. Switch and Slider thumbs also have no "selected" state. Could those lines carry the exception, with a decision entry for the lift in this record?
|
FR9 says label weights change only when the drag starts; the implementation and UIKit's measurement change them at the lift (#8127's proofs: no weight change mid-drag). Should it read 'only at the lift'? The FR7/FR8 verification row lists "a theme that sets a dim and a lift" and "a look that ignores the theme roles", while FR7 says no theme role dims a segment; is "a dim" there a leftover? |
…ole, segmented.selectionSpring The record owner's SegmentedControl record (meta#8596) has the slide play on the internal `segmented.*` motion roles with UIKit's measured values (`spec:AST-094` FR4, DEC-11). `registerSegmentedTable` registers the slide's spring as `segmented.selectionSpring`, named in FR4's role table; the selection motion registers it before its first animation. The value is unchanged, and no theme retunes it while the role stays internal: the resolver still plays the table's value. The registration moves here from the touch-tracking pull request, where the slide's spring was registered with the lift's and the pressed title's roles (since withdrawn). The unit proof that the slide's spring is the role failed before the change.
…l request no longer edits it The record owner's meta#8596 records SegmentedControl's touch presentation (FR5–FR10, DEC-1, PR1). Its FR5 and FR6 are this pull request's slide, so the record rows, verification row, Intent and compatibility lines this pull request had added are dropped in favor of hers, and the record stays as the base has it.
Decided (Cindy, 2026-10-26: D33).
User impact
On a phone, a person can slide SegmentedControl's selection to another segment and see it travel, as on iOS. A held segment keeps today's pressed overlay. A theme can add a lift to the pressed thumb; shipped themes don't, so they look exactly as before. A mouse is unchanged.
Records
component:SegmentedControl(draft):::before) on internalsegmented.*motion roles, with a Reduce Motion cross-fade. This followsspec:AST-094.design:user-statesDR1), with no theme role to dim it.family:action-groups(spec(family): action groups — press, slide across, act on lift (AST-094 FR26–FR28) #8622).design:user-statesDR3: a theme may own one press treatment on a selected thumb, the general pressed-thumb lift. It applies only while pressed, is none by default, and a Switch thumb stays circular. The anatomy row is updated to match.Measured behavior comes from #8127. No component-specific theme token is added.
Writing rubric results