Changing the theme colours
Check whether a built-in will do first: the built-in themes are sorted by document type, each with its own palette and layout, and one flag switches between them.
This page is about tweaking when none of them quite fits — a <style> block in the source file overriding CSS variables. The two combine: pick a theme, then override a value or two.
Change the accent colour
Links, the active tab underline and the step circles all follow — their defaults derive from --pf-primary.
This works because raw HTML passes through untouched.
Change a whole palette
What you write on :root is what the screen shows — the output is always dark and never consults the reader's system setting, so these should be your dark values:
Leaving the @media print block out is fine: printing then falls back to the built-in theme's own light values, which is usually what you want.
All 18 semantic variables are in Theme tokens.
Change one thing only
Element-layer variables derive from the semantic layer, so you can override just one:
Diagrams follow too
Diagram colours come from six variables in the same set:
Hard-coded colours in engine output that could not be substituted report DIAG-304 and are listed — those will not follow the theme.
Three costs
<style> block has no limits
It can override the whole theme system, including parts you did not intend to touch. A misspelled variable name produces no warning of any kind.
- Every document repeats it. There is no shared config; the source file carries all configuration. To swap a whole theme, use
--themeor frontmatter instead of repeating this. - It affects the output, not the source's readability. On GitHub that
<style>shows up as plain text. - Variable names may change during 0.x. Renaming is expensive (substitution rules, built-in themes and docs must change together), but nothing is promised.