A selected Dropdown option lacks a token-based focus treatment in normal colors

[woksin]

What happens

In @cratis/components 4.1.0, keyboard focus on a selected Dropdown option is rendered with Chromium's default saturated-blue rectangular outline. The package styles focused and selected option backgrounds/text in normal colors, but defines a deliberate option outline only in forced colors, so the normal-color stable option state never consumes the public Cratis focus token.

This is not an absent-focus claim: the browser default remains visible. The defect is that the package-owned option state leaks a user-agent style instead of providing a token-based normal-color treatment.

Evidence

The evidence is bound to exact tag v4.1.0 (c4c4cc9a13c6416eb3ab31701546e961b4e9da72):

• DropdownImplementation.tsx renders the stable .cratis-dropdown__option / data-cratis-part='option' with selected state.
• Dropdown.css gives normal-color focused and selected options background/text styling only. The only explicit option outline is 2px solid Highlight inside @media (forced-colors: active).
• The consumer already maps --cratis-focus-ring, selected background, and selected text tokens. A current keyboard-focused selected option still shows the browser's bright-blue outline.

What it costs a consumer

The current result falls outside the consumer's token-driven focus language on every Dropdown surface. A local selector against .cratis-dropdown__option[data-focused] would duplicate package state ownership and couple the consumer to package DOM/CSS. The cost is visual and accessibility consistency rather than lost functionality, but it leaves the advertised focus-token contract incomplete for this stable part.

Suggested fix — the seam

Define a deliberate normal-color keyboard-focus treatment for the stable Dropdown option state that consumes the public Cratis focus token. Keep focused and selected states distinguishable in light and dark themes and preserve the existing forced-colors Highlight treatment. Add package-owned normal-color and forced-colors coverage.

What is explicitly not being asked for

• No global suppression of focus indication and no removal of the forced-colors outline.
• No prescribed outline width, offset, radius, or other CSS bytes beyond consuming the public token contract.
• No consumer selector against package or React Aria internals.
• No redesign of Dropdown selection colors or the consumer theme.

Related, not duplicate

#211 is broad cross-browser and assistive-technology certification work. It is related, but it does not describe or settle this atomic normal-color selected-option focus-style defect.

[cratis-direct]

Investigation

I reproduced the bug in a real browser and confirmed it's slightly worse than reported — it has two distinct faces, one per Dropdown code path.

Reproduction (Storybook dev at localhost:6006, headless Chromium via Playwright, Dropdown/Dropdown stories, baseline-light and baseline-dark):

Select path (StateMatrix, second control with Developer selected) — Tab to the trigger, press Enter:

active element: div.cratis-dropdown__option  data-selected=true  data-focused=true  data-focus-visible=true
:focus-visible matches: true
computed outline:     rgb(16, 16, 16) auto 1px   ← user-agent ring, painted
computed box-shadow:  none                       ← --cratis-focus-ring never consumed

The option is the real document.activeElement, so Chromium paints its own ring. Screenshot confirmed a UA ring drawn around the selected option, clipped flush against the popover edge.

Filterable/ComboBox path (FilteredAndOpen, value selected, reopened with ArrowDown) — focus stays virtual on the input, so there is no UA ring, and the focused+selected option computes box-shadow: none, background: rgb(239,246,255), i.e. identical to a merely-selected option. [data-selected] follows [data-focused] at equal specificity in Dropdown.css, so the focus background is overridden and keyboard position is invisible.

Mouse-opening the Select path gives data-focused=true, data-focus-visible=false — so [data-focus-visible] is the correct seam for the ring.

I also validated a candidate fix live by injecting .cratis-dropdown__option { outline: none } .cratis-dropdown__option[data-focus-visible] { box-shadow: inset var(--cratis-focus-ring) }: the token ring renders fully inside the option (an outward ring would be clipped by the popover's overflow: auto), stays distinguishable from the selected background in both light (#2563eb on #eff6ff) and dark (#93c5fd on the dark highlight), and the UA ring is gone.

SUGGESTED-MODEL: sonnet

Plan for #240

Settled — do not redo

• Reproduced, evidence above. Both paths render .cratis-dropdown__option from the same class, so one CSS rule set covers all three renders in Source/Dropdown/DropdownImplementation.tsx (Select ~line 698, filtered single ~line 551, filtered multiple ~line 332). No TSX change is needed — data-focused / data-focus-visible / data-selected are already on the DOM.
• The whole fix lives in Source/Dropdown/Dropdown.css (lines 123–156), reached through the Source/styles.css manifest.
• The seam is [data-focus-visible], not [data-focused]: hovering sets data-hovered only, and mouse-opening sets data-focused without data-focus-visible. Keying on data-focused would paint a ring on pointer-opened dropdowns.
• The ring must be inset (inset var(--cratis-focus-ring), or outline with a negative outline-offset). The popover is overflow: auto, so an outward ring is clipped. Repo precedent for inset exists at Source/Common/DatePickerInput.css:81.
• The house pattern to mirror is .cratis-date-picker__cell (Source/Common/DatePickerInput.css:139–158): base rule carries outline: none, the focus state carries box-shadow: var(--cratis-focus-ring).
• Keep the forced-colors block intact. .cratis-dropdown__option[data-focused] inside @media (forced-colors: active) has higher specificity than the base rule, so adding outline: none to the base rule does not disturb it. Forced colors ignores box-shadow, which is exactly why the Highlight outline must stay.
• Scope is Dropdown only. Nothing else in Source or Adapters references cratis-dropdown__option.

Implementation

1. In Source/Dropdown/Dropdown.css, on .cratis-dropdown__option: add outline: none to the base rule and add a [data-focus-visible] rule consuming inset var(--cratis-focus-ring). Order it after [data-selected] so the focused-and-selected combination keeps both the selection background and the ring — this is what fixes the ComboBox-path indistinguishability.
2. Leave the existing [data-focused] background and the @media (forced-colors: active) block unchanged.

Coverage (the issue explicitly asks for both)

3. Normal-color + forced-colors CSS-source spec — new Source/Dropdown/for_Dropdown/when_styling_option_focus.ts, following the postcss idiom already in Source/for_theme/when_resolving_explicit_color_schemes.ts and Source/Filter/for_FilterPanel/when_sharing_the_pv_namespace_with_pivot_viewer.ts. Assert the focus rule resolves var(--cratis-focus-ring), that it is ordered after [data-selected], and that the forced-colors Highlight outline survives. Runs under yarn test.
4. Rendered browser assertion — a play function on a new (or the existing) Dropdown.stories.tsx story that Tabs to a dropdown with a value selected, opens it with the keyboard, and asserts the focused option's computed box-shadow is non-none while no UA ring is relied on. CI already runs yarn test-storybook in baseline-light and baseline-dark (.github/workflows/javascript-build.yml:137), so this covers both themes for free.

Gates

yarn lint · yarn test · yarn workspace @cratis/components build-storybook · yarn test-storybook. PR label: patch — shipped CSS changes what a consumer observes, so no-release does not apply.

Needs a human decision (non-blocking; sensible defaults exist)

• Ring geometry. The issue explicitly declines to prescribe width/offset/radius. An inset var(--cratis-focus-ring) (3px in both baseline themes) fills the option's 0.75rem padding comfortably — verified visually — but a designer may prefer a thinner ring or a negative-offset outline over an inset box-shadow. Either satisfies the token contract.
• Whether to also add a [data-hovered] treatment. Hovering an option currently styles nothing in the ComboBox path (data-hovered has no rule). That is a real gap, but the issue says "no redesign of Dropdown selection colors" — I'd leave it out and open a separate issue.
• Whether sibling RAC collections deserve the same sweep. ActionMenubar, DataPageLayout, DataPage, and SchemaEditor also render RAC item components and may leak the same UA ring. Out of scope for this atomic issue; worth a follow-up issue rather than widening this PR.

Suggested model for implementation: sonnet

---

Posted by Stagehand (AI) - an autonomous agent, not a person. Review accordingly.