Repository navigation
Conversation
Under spec:AST-094 FR43 the press controller paints a mouse's or a pen's press too (data-astryx-press), not only a finger's. Tab painted its pressed image only inside @media (pointer: coarse), so a mouse press showed nothing but :active's colour, with no release fade. - Its image arms paint the controller's press for every pointer. - Its hover and pressed colours yield while the press is on, so a press never paints twice, and paint again over the release, so a hovering pointer's release lands on the tab's hover (as the shared overlay does). Checkbox and Radio are #8696's; Switch is #8681's. Test: Tab's compiled CSS paints both arms outside the coarse media.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
AI review status for this pull request.
|
PR Analysis Report
|
There was a problem hiding this comment.
Recommending approval: a mouse or pen press on a tab now paints through the press controller at once and fades onto the hover tint, as spec:AST-094 FR11 and DEC-21 require, and the new source-build test fails on the base and passes here. This lands after its base, #8727. An optional follow-up: under Reduce Motion the release shows the bare tab for one frame before the hover returns, as TopNav items already do through the shared overlay, and a 0s colour transition on the hover layer under prefers-reduced-motion: reduce would remove it.
[Automated review]
There was a problem hiding this comment.
Recommending approval: a mouse or pen press on a tab now paints through the press controller at once and its release fades onto the hover tint, as spec:AST-094 FR11 and DEC-21 require, and the new source-build test fails on the base and passes here. This lands after its base, #8727. An optional follow-up: under Reduce Motion the release shows the bare tab for one frame before the hover fades back in, as TopNav items already do through the shared overlay, and a 0s colour transition on the hover layer under prefers-reduced-motion: reduce would remove it.
[Automated review]
User impact
On desktop, a mouse or pen press on a tab showed only CSS
:active's colour: no press from the controller and no release fade, while a finger got both. Underspec:AST-094FR43 every pointer presses the same way.After this change, a mouse press on a tab paints the controller's press layer, and the release lands on the tab's hover tint.
Problem and solution fit
@media (pointer: coarse), so the controller'sdata-astryx-presspainted nothing for a mouse.Expected behavior and authority
spec:AST-094FR11 and FR43 (DEC-21).Smallest restoration
TabList/Tab.tsxonly, plus a source-build test. It's stacked on the release-lands-on-hover PR, fix(core): a mouse release lands on the hover the control still has #8727.Evidence
:active's colour only, then a jump on release (235 → 242).:active).pressEveryPointer.source-build.test.mjschecks that Tab's compiled CSS paints both press arms outside the coarse media.Scope
Testing
pnpm vitest run packages/core/src/TabList packages/core/src/utilspnpm -F @astryxdesign/core typecheckSupersedes #8714.