Problem
--header-background is used both as the header color and as a generic surface color for components like .copy-code-button, the search dialog, and others:
.copy-code-button {
background-color: var(--header-background);
border: 1px solid var(--header-border);
/* ... */
}This works fine when the header is a neutral/light color, but themes that use a dark or strongly-colored header end up with mismatched component surfaces (e.g. a black square for the copy button on a light code block).
Suggestion
Introduce a dedicated variable (e.g. --surface-background and --surface-border) for component backgrounds that are currently borrowing --header-background. The header variables would remain for the actual header, and the new surface variables would default to the header values for backwards compatibility:
:root {
--surface-background: var(--header-background);
--surface-border: var(--header-border);
}
.copy-code-button {
background-color: var(--surface-background);
border: 1px solid var(--surface-border);
}This way, themes that want a dark header with light content surfaces can override --surface-background independently without having to target each component individually.
Affected components
From a quick scan of fsdocs-default.css, these reference --header-background outside of the actual header:
.copy-code-button--aside-background--blockquote-bacground-color--mobile-menu-background--page-menu-background-color--dialog-background-color
Problem
--header-backgroundis used both as the header color and as a generic surface color for components like.copy-code-button, the search dialog, and others:This works fine when the header is a neutral/light color, but themes that use a dark or strongly-colored header end up with mismatched component surfaces (e.g. a black square for the copy button on a light code block).
Suggestion
Introduce a dedicated variable (e.g.
--surface-backgroundand--surface-border) for component backgrounds that are currently borrowing--header-background. The header variables would remain for the actual header, and the new surface variables would default to the header values for backwards compatibility:This way, themes that want a dark header with light content surfaces can override
--surface-backgroundindependently without having to target each component individually.Affected components
From a quick scan of
fsdocs-default.css, these reference--header-backgroundoutside of the actual header:.copy-code-button--aside-background--blockquote-bacground-color--mobile-menu-background--page-menu-background-color--dialog-background-color