Improve line and border color on webpages when brand is used

[cwickham]

Bug description

Particularly in examples with a dark background a lot of lines and borders are white with no easy way to control them.

Steps to reproduce

Preview this webpage project: index.qmd and _quarto.yml

index.qmd:

---
title: "lines"
toc: true
brand:
  color:
    background: "#222"
    foreground: "#ee7"
    primary: "rgb(238, 163, 0)"
---

## Section

```{.r filename="Filename"}
# CODE
```

## Another section

_quarto.yml:

project:
  type: website

website:
  sidebar:
    contents:
      - href: index.qmd
        text: Home

Expected behavior

Borders and lines should probably inherit from foreground, or the element they are surrounding.

Actual behavior

Lots of lines and borders aren't a great color by default:

• TOC border on in-active sections
• Border around search box
• Line under <h2> header
• Border around a code cell
• Line under the sidebar when it is collapsed on a small screen

Some of these can be controlled by $table-border-color, e.g:

brand:
  color:
    background: "#222"
    foreground: "#ee7"
    primary: "rgb(238, 163, 0)"
  defaults:
    bootstrap:
      defaults:
        table-border-color: black

But, it's unintuitive to use something called table-border-color (especially since it doesn't actually change the color in <table> elements).

Your environment

No response

Quarto check output

$ quarto check
Quarto 99.9.9
[✓] Checking environment information...
      Quarto cache location: /Users/charlottewickham/Library/Caches/quarto
[✓] Checking versions of quarto binary dependencies...
      Pandoc version 3.4.0: OK
      Dart Sass version 1.70.0: OK
      Deno version 1.46.3: OK
      Typst version 0.11.0: OK
[✓] Checking versions of quarto dependencies......OK
[✓] Checking Quarto installation......OK
      Version: 99.9.9
      commit: bf93178346e68f721714ef4c7f792943b4d80f6e
      Path: /Users/charlottewickham/Documents/posit/quarto-cli/package/dist/bin

[✓] Checking tools....................OK
      TinyTeX: v2024.03.13
      Chromium: (not installed)

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

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

[✓] Checking Python 3 installation....OK
      Version: 3.12.1
      Path: /Users/charlottewickham/Documents/posit/quarto-web/.venv/bin/python
      Jupyter: 5.7.2
      Kernels: julia-1.10, ark, python3

[✓] Checking Jupyter engine render....OK

[✓] Checking R installation...........OK
      Version: 4.3.3
      Path: /Library/Frameworks/R.framework/Versions/4.3-arm64/Resources
      LibPaths:
        - /Users/charlottewickham/Library/R/arm64/4.3/library
        - /Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/library
      knitr: 1.45
      rmarkdown: 2.28

[✓] Checking Knitr engine render......OK

[cscheid]

I think we should do this in 1.8, because we will need to change our styles and that has a lot of downstream implications.

Case by case:

Cases 1, 2, 3, 4

This is $border-color; the problem is that the default style has $gray-300. Arguably, it should be something like mix($foreground, $background, 30%)

Case 5

This is $toc-inactive-border; the problem is that the default style has $gray-200. Arguably, it should be something like mix($foreground, $background, 20%)

Additional weirdness

Suppose we add the following two entries to a style.scss:

theme:
  - theme.scss

/*-- scss:defaults --*/

$border-color: mix($background, $foreground, 70%);
$toc-inactive-border: mix($background, $foreground, 80%) !default;

This doesn't work because the ordering is wrong, and needs the following instead:

theme:
  - theme.scss
  - brand

That solves the problem. But notice two strange things:

• somehow, border-color must not be !default, while toc-inactive-border can be !default (which is what we generally recommend)
• note the interplay between brand and theme variables. If themes use brand variables (in this case $background and $foreground), then brand needs to be defined after the theme, so that the variables are declared first, and SCSS !default semantics + our reordering works correctly. This is very unintuitive.

[cscheid]

We can't really solve this well unless we increase the uniformity of SCSS variable declaration among our themes, formats and defaults. I think we should make the change.

If we make this change, Quarto's "bootswatch" themes will be slightly different from true bootswatch themes, but I think the improvement is well worth it. In addition, it will allow us to eventually do the same thing for other styling subsystems such as diagrams.