Select-kit dropdown: selected/highlighted items have poor color contrast, text and icons disappear

Support
1

When using the topic notification dropdown (Watching/Tracking/Normal/Muted), the currently selected item’s text and icon become invisible due to insufficient contrast between the selection background color and foreground colors.

Steps to reproduce

  1. Open any topic

  2. Click the notification bell button at the bottom of the topic

  3. Observe the currently selected notification level (e.g., “Tracking”)

Expected behavior

The selected item should have clearly visible text and icon with good contrast.

Actual behavior

  • Text label disappears or becomes very hard to read

  • Bell icon becomes invisible

  • Issue is most noticeable in dark themes but can affect any theme depending on color palette

Technical details

In app/assets/stylesheets/common/select-kit/select-kit.scss, the .is-selected state only sets the background color without ensuring foreground contrast:

&.is-selected,
&.is-selected.is-highlighted {
  background: var(--d-selected);
  // No color override for text or icons
}

The --d-selected CSS variable comes from the theme’s $selected color, but the text (.name, .desc) and icons (.d-icon) retain their default colors which may not contrast well with the selection background.

Screenshots

image
image531×470 11.9 KB

Note: I would have added the other image where the icon disappears for the seelcted state, but i’m new and can only add one image right now.

Environment

  • Discourse version: latest

  • Browser: Edge

  • Theme: Foundation theme

2 Likes
3

This is a restriction for new users. You can browse some existing topics so that your trust level can quickly rise to 1.

5

I am not able to reproduce this bug.

image
image479×406 22.3 KB

7

@BrettH Does this happen in safe mode?

8

It looks like your color palette hasn’t been updated in a while maybe, because that’s not the normal selected colour. When did you last update your forum?

2 Likes
9

Could it be related to

?

10

Yeah this is likely the case — I’ve seen situations like this where a custom color palette that was created before new colors were added ends up with poor contrast… @BrettH if you create a new color palette and use that, does the issue persist?

2 Likes
11

Thanks everyone for the suggestions. Let me address the questions:

NateDhaliwal - I haven’t tested in safe mode yet, but based on what chapoi and Kris are describing, I suspect safe mode would resolve it since it would fall back to the default Light palette rather than my custom one.

@chapoi - Good question. Our color palette was created quite a while ago - definitely before the selected and hover colors were added to the base palette. I believe the palette was set up when we first launched the community, and we haven’t updated it since.

@awesomerobot - That makes sense. Looking at the code, I can see that resolved_colors computes fallback values for hover and selected using dark_light_diff if they’re missing from the palette. But the problem is the text colors (.name, .desc, .d-icon) still use their default values, which were designed for the default Light palette’s selection color - not the computed fallback for my darker theme.

I’ll create a new palette and explicitly set the selected and hover colors to values that contrast properly. I suspect that will fix it.

One thought while I’m testing: would it make sense for the fallback calculation to also consider text contrast? That way older palettes would gracefully handle new color additions without manual intervention. Just an idea - I know color systems are tricky to get right, and the current approach probably covers most cases. Happy to file a separate feature request if that’s helpful.

Thanks for the help tracking this down!

2 Likes