Can't read navbar dropdown menu and tool items in dark mode

[EllaKaye]

I have:

• searched the issue tracker for similar issues
• installed the latest version of Quarto CLI
• formatted my issue following the Bug Reports guide

Bug description

With a custom dark theme, for both drop down menu items and drop down tool items, the background of the items on the menu are dark (as expected), but when hovered over, the items by default get a light background colour. Because the text by default is light, this makes the text unreadable.

Menu item without hover:

Menu item with hover:

It is possible to fix both of these with additional custom CSS, i.e.

.navbar-nav .dropdown-menu .dropdown-item:hover,
.dropdown-item.quarto-navbar-tools-item:hover {
    background-color: #200F48;
}

but I think this is something that toggling to dark mode should adjust automatically with a colour derived from $body-bg.

I have checked on both the release and the latest pre-release (1.8.18) - the issue occurs on both.

Steps to reproduce

The minimal reprex repo is at https://github.com/EllaKaye/navbar-enhancement and the corresponding site is at https://ellakaye.github.io/navbar-enhancement/.

The issue occurs both on the dropdown from the "Other" navbar item, and from the GitHub logo.

This is _quarto.yml:

project:
  type: website

website:
  title: "navbar-enhancement"
  navbar:
    left:
      - href: index.qmd
        text: Home
      - text: Other
        menu:
          - about.qmd
    tools:
      - icon: github
        menu:
          - text: Source Code
            url: https://github.com/EllaKaye/navbar-enhancement
          - text: Report a Bug
            url: https://github.com/EllaKaye/navbar-enhancement/issues


format:
  html:
    theme:
      light: theme-light.scss
      dark: theme-dark.scss

And this is theme_dark.scss:

/*-- scss:defaults --*/

$dark: #0C0721;

$body-bg: $dark;
$body-color: white;

and this is theme_light.scss:

/*-- scss:defaults --*/

$dark: #0C0721;

$body-color: $dark;

Actual behavior

Hovering over a navbar dropdown menu or tool item in dark mode from a custom theme gives it a light background colour.

Expected behavior

Hovering over a navbar dropdown menu or tool item in dark mode from a custom theme should give it a dark background colour, derived from $body-bg.

Your environment

• IDE: 2025.07.0 build 204
• MacOS: 15.6

Quarto check output

Quarto 1.7.32
[✓] Checking environment information...
      Quarto cache location: /Users/u2175871/Library/Caches/quarto
[✓] Checking versions of quarto binary dependencies...
      Pandoc version 3.6.3: OK
      Dart Sass version 1.85.1: OK
      Deno version 1.46.3: OK
      Typst version 0.13.0: OK
[✓] Checking versions of quarto dependencies......OK
[✓] Checking Quarto installation......OK
      Version: 1.7.32
      Path: /Applications/quarto/bin

[✓] Checking tools....................OK
      TinyTeX: v2022.11
      Chromium: (not installed)

[✓] Checking LaTeX....................OK
      Using: TinyTex
      Path: /Users/u2175871/Library/TinyTeX/bin/universal-darwin
      Version: 2022

[✓] Checking Chrome Headless....................OK
      Using: Chrome found on system
      Path: /Applications/Google Chrome.app/Contents/MacOS/Google Chrome
      Source: MacOS known location

[✓] Checking basic markdown render....OK

[✓] Checking Python 3 installation....OK
      Version: 3.12.1
      Path: /Users/u2175871/.pyenv/versions/3.12.1/bin/python3
      Jupyter: 5.7.2
      Kernels: python3

(|) Checking Jupyter engine render....Traceback (most recent call last):
  File "/Applications/quarto/share/jupyter/jupyter.py", line 21, in <module>
    from notebook import notebook_execute, RestartKernel
  File "/Applications/quarto/share/jupyter/notebook.py", line 15, in <module>
    from yaml import safe_load as parse_string
ModuleNotFoundError: No module named 'yaml'
[✓] Checking Jupyter engine render....OK

This issue is still present on the latest pre-release (1.8.18).

[xx02al]

Hi @EllaKaye

I've just seen this issue you opened. I think the behavior you're seeing is actually expected and correct (i.e., not a bug); it's related to how Quarto and Bootstrap handle theme inheritance.

Explaining your actual case

When you provide a custom theme - and only that -, you will inherit from the default Bootstrap theme.

So in your case, light: theme-light.scss and dark: theme-dark.scss both inherit from the default Bootstrap theme. The dropdown background color ($dropdown-bg) is the body background color and it is $dropdown-color: var(--#{$prefix}body-color) !default; as given by https://github.com/twbs/bootstrap/blob/e52e3b1c95e82127391c76c7c3c846410aec51d3/scss/_variables.scss#L1244. Furthermore, the dropdown hover background color is a pretty light grey (nearly "white").

Maybe this illustration helps you: update your theme-light.scss like so

/*-- scss:defaults --*/

$dark: #0C0721;
$pinkish: #FFB6C1;

$body-bg: $pinkish;
$body-color: $dark;

Options to resolve your issue

One way is to continue inheriting from the default Bootstrap theme and complete your theme-dark.scss file so that it meets your requirements. In your case (with $body-bg: $dark and $body-color: white;), you especially want to define $dropdown-link-hover-bg. For example

/*-- scss:defaults --*/

$dark: #0C0721;
$darkviolet: #452387;

$body-bg: $dark;
$body-color: white;
$dropdown-link-hover-bg: $darkviolet;

Of course, you would then add further Sass variables and most likely also add some /*-- scss:rules --*/ to get your "good" dark theme.

Another option is to provide a Bootswatch theme that already is dark mode like, for example Darkly, along with your theme-dark.scss. In this case, customize your theme in your _quarto.yml like so:

format:
  html:
    theme:
      light: theme-light.scss
      dark: 
        - darkly
        - theme-dark.scss

Darkly, as an example, also uses $body-bg as dropdown background color and $body-color as the dropdown item "text" color, but since $body-color is bright, body-bg is dark, $primary is #375a7f (a blue) and $dropdown-link-hover-bg: $primary !default;, the text is still readable when you hover over the dropdown item.

Here are another example to support your understanding. After you added the darkly theme in your _quarto.yml, update your theme-dark.scss like so (note that the $greenish is only used to emphasize the example)

/*-- scss:defaults --*/

$dark: #0C0721;
$greenish: #d7e6adff;

$body-bg: $dark;
$body-color: $greenish;

[mcanouil]

Thanks.

FYI, Quarto already made many changes to Bootswatch themes for them to have "better" defaults in Quarto's context as Quarto offers a specific way to use dark/light mode.

For instance, there is a very similar issue with tooltips (which can be worked around the same way as demonstrated here):

• Light/dark mode leads to low background/colour contrast tooltip #13195

[EllaKaye]

Hi @xx02al. Thanks for the explanation. I didn't know about $dropdown-link-hover-bg - that is certainly a better fix than the custom css that I was using.

I still think, though, that this is something that Quarto could/should change as a 'better' default, as @mcanouil suggests.

It is also an issue with brand.yml, not just with custom SCSS.

Suppose, for example, we ditch the theme-dark.scss and theme-light.scss files that I had before and instead use two brand files:

light-brand.yml:

color:
  background: "#FFFFFF"
  foreground: "#0C0721"

dark-brand.yml:

color:
  background: "#0C0721"
  foreground: "#FFFFFF"

and the following in _quarto.yml:

brand:
  light: light-brand.yml
  dark: dark-brand.yml

Then there is still the issue of the light background colour on hover on the navbar dropdown items and therefore not being able to read the text. For brand.yml, which is supposed to be simple and provide 'good-enough' branding, I would absolutely expect Quarto to change the $dropdown-link-hover-bg colour in dark mode on the basis of a very minimal dark brand.yml specification and I would consider that to be a bug.

I have updated my reprex at https://github.com/EllaKaye/navbar-enhancement and https://ellakaye.github.io/navbar-enhancement/ for the brand.yml version of this bug.

[xx02al]

#13195 (comment)