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 Open any topic Click the notification bell button at the bottom of the topic 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] 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

[imagem] BrettH: 𝑁𝑜𝑡𝑒:𝐼𝑤𝑜𝑢𝑙𝑑ℎ𝑎𝑣𝑒𝑎𝑑𝑑𝑒𝑑𝑡ℎ𝑒𝑜𝑡ℎ𝑒𝑟𝑖𝑚𝑎𝑔𝑒𝑤ℎ𝑒𝑟𝑒𝑡ℎ𝑒𝑖𝑐𝑜𝑛𝑑𝑖𝑠𝑎𝑝𝑝𝑒𝑎𝑟𝑠𝑓𝑜𝑟𝑡ℎ𝑒𝑠𝑒𝑒𝑙𝑐𝑡𝑒𝑑𝑠𝑡𝑎𝑡𝑒,𝑏𝑢𝑡𝑖′𝑚𝑛𝑒𝑤𝑎𝑛𝑑𝑐𝑎𝑛𝑜𝑛𝑙𝑦𝑎𝑑𝑑𝑜𝑛𝑒𝑖𝑚𝑎𝑔𝑒𝑟𝑖𝑔ℎ𝑡𝑛𝑜𝑤. This is a restriction for new users. You can browse some existing topics so that your trust level can quickly rise to 1.

I am not able to reproduce this bug. [image]

@BrettH Does this happen in safe mode?

[imagem] BrettH: 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. 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?

Could it be related to [imagem] Discourse Free Plan setup - options are hard to read UX Thanks for the details @NateDhaliwal. My hunch is that it’s related to that missing CSS var when light/dark mode is involved, and how it’s compiled via PostCSS. It looks like the browser may be falling back to the light mode background color, which is odd since I can’t reproduce this. Judging by the screenshots, my fix hadn’t been deployed to your instance yet. It should be deployed there now, so give it another try and let me know if you still notice anything off. ?

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?

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!

Dropdown Select-kit: itens selecionados/destacados têm baixo contraste de cor, texto e ícones desaparecem

Suporte ao Produto

Canapin (Coin-coin le Canapin) 18 Fevereiro , 2026 09:03 9

Poderia estar relacionado a

Tópico		Respostas	Vistas
Theme highlight color when selecting text to quote on Dark color palettes Product Support	5	668	1 Março , 2019
Dark/light mode toggle now available in core Announcements	27	3391	17 Março , 2025
Colors changed in beta7? Product Support	5	1133	5 Janeiro , 2019
Accessibility: Color contrast Feature accessibility	13	3112	18 Janeiro , 2018
Topic Bulk Selector is adding a brightening filter to it Product Support	1	121	22 Fevereiro , 2026

Dropdown Select-kit: itens selecionados/destacados têm baixo contraste de cor, texto e ícones desaparecem

Related topics