Repository navigation
Conversation
Tailwind v4.3.3 drops the whole parent selector when a selector that
starts with the universal selector (e.g. `*:not(body):not(.focus-override)`)
uses `&` nesting. The three nested focus-visible rules in globals.css all
collapsed into a single bare `:focus-visible { ... }` block, so every
focused element got the last rule's 2px `.link` ring — including
`.focus-override` opt-outs like composer inputs (a stray grey ring) and the
menu surfaces whose ring was meant to be suppressed.
Flatten the three rules to equivalent single selectors (same specificity
and cascade order) and add a test that keeps CSS nesting out of
globals.css while the upstream bug stands.
morgmart
left a comment
There was a problem hiding this comment.
🤖 Automated code review
REQUEST_CHANGES: The exact PR comparison contains no publishable implementation findings. It changes visible keyboard focus indicators in Berd's graphical interface, but the supplied GitHub evidence contains no screenshots or short screen recording. All 11 supplied GitHub check runs completed successfully.
Deterministic publication result: 0 blocking and 0 non-blocking inline finding(s) publishable; 0 duplicate(s) suppressed; 1 blocking screenshot-evidence requirement(s) in this review body.
🤖 Blocking · Screenshots needed
This PR changes Berd’s graphical interface. Please add screenshots or a short screen recording so the visual result can be reviewed. Screenshots are review evidence; they do not replace accessibility, responsive, theme, localization, or behavior validation.
|
🤖 Added before/after screenshots (synthetic renders, no user data) to the PR description per the review. |
Problem
Every focused element, including inputs that opt out of the global focus ring with
.focus-override, shows a focus ring. In composer text inputs it appears as a grey square ring inside the input. Menu surfaces whose ring is meant to be suppressed also show one.Cause
Tailwind v4.3.3 drops the whole parent selector when a selector that starts with the universal selector
*uses&nesting:It isn't specific to
@applyor:focus-visible.*:not(.b) { &:hover { color: red } }also compiles to a bare:hover, while.c { &:focus-visible { ... } }compiles correctly.globals.csshad three of these*-led nested rules: the base ring, the menu-surface suppression, and.link. All three compiled into one bare:focus-visible { ... }block, and the last rule wins, so every focused element got the 2px.linkring.Fix
*:not(body):not(.focus-override):focus-visible). Specificity and cascade order stay the same, because&on a single compound parent desugars to an equivalent:is().globals.test.tsthat rejects&nesting inglobals.css(the@custom-variantdefinition is allowed) and asserts the three flattened selectors, so the nested form can't come back while the upstream bug stands.Verification
dist/assets/index-*.cssnow contains:not(body):not(.focus-override):focus-visible,...menubar-sub-trigger]):focus-visibleand the.linkselector, and no bare}:focus-visible{.main'sglobals.cssand passes with the fix.pnpm vitest run src/shared/stylesandjust checkpass..focus-overrideuses were checked; none loses a real focus indicator. Five aretabIndex={-1}panels, one is a dialog with its ownfocus-visible:outline-none, and one is the global composer textarea, which keeps its caret andgroup-focus-withinstyling.Screenshots
Synthetic renders in WebKit with the real globals.css and Desktop Agent composer component; no real user data.
Before (reproduction): the composer input picks up the global ring and shows a grey box inside the text field.

After: the
.focus-overrideinput has no ring, and an ordinary button still shows the global focus ring.