posit-dev / posit-dev/positron

Consider a selection background tint for HC Dark lists (list.inactiveSelectionBackground is null in hcDark

Open
#15,411 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

accessibility area: ui
Dominant language
TypeScript
Stars
4.3k
Forks
184
Avg merge
1d 11h
Merged PRs (30d)
206

Description

Context

While fixing the invisible active console session tab in Dark High Contrast
(#15405), we noticed an asymmetry in the upstream list color defaults
(src/vs/platform/theme/common/colors/listColors.ts):

export const listInactiveSelectionBackground = registerColor('list.inactiveSelectionBackground',
	{ dark: '#37373D', light: '#E4E6F1', hcDark: null, hcLight: Color.fromHex('#0F4A85').transparent(0.1) },

HC Light gets a subtle 10% tint for inactive selection; HC Dark gets nothing.
Any component that (reasonably) uses list.inactiveSelectionBackground as a
selection cue is invisible in HC Dark unless it also implements the outline
convention. #15405 fixed the console session tabs with a contrastActiveBorder
outline, but the question of whether HC Dark should also get a background tint
was deferred to this issue (raised in review).

Why this wasn't just fixed in #15405

The null appears deliberate rather than an oversight:

It has been hcDark: null since before Positron forked (already null in our
2022-05-24 history import) and is unchanged upstream since.
It was left null in the very edit that introduced hcLight with a tint --
the hc -> hcDark/hcLight split touched this exact registration, so the
author chose null for HC Dark while giving HC Light a value.
HC Dark's design language conveys list state with outlines only
(contrastActiveBorder / list.focusOutline); HC Light was designed later
with a tint system layered on top of outlines.
Changing the default would also:

Affect every list/tree in the workbench for HC Dark users (explorer, search,
quick picks, ...), not one component -- it's a theme-wide design decision.
Require editing an upstream file (listColors.ts), a permanent
merge-conflict liability for something upstream arguably owns.

Options
  1. Do nothing -- keep the outline-only convention for HC Dark; components
    must implement outlines (as #15405 does). Users who want a tint can set:
"workbench.colorCustomizations": {
    "[Dark High Contrast]": {
        "list.inactiveSelectionBackground": "#ffffff1a"
    }
}
  1. Propose the change upstream (microsoft/vscode) -- e.g.
    hcDark: Color.white.transparent(0.1) to mirror HC Light -- and inherit it
    through a future merge. Keeps us aligned and puts the accessibility design
    question in front of the theme owners.

  2. Positron-local override -- set the value in our fork. Fastest, but the
    merge-liability and design-ownership concerns above apply.
    Recommendation: decide with design/accessibility input; if we want the tint,
    option 2 first.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with src/vs/platform/theme/common/colors/listColors.ts and review the related console session tab work in #15405. Consult the design and accessibility owners on whether HC Dark should keep outline-only selection or receive a tint, then document the decision and whether the change belongs upstream, locally, or nowhere.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
accessibility, design
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.