Should a Bulma theme rely on Sass variable overrides or CSS custom properties for runtime switching?
0 reputation · 28 Oct 2021, 10:22 UTC
0 reputation · 28 Oct 2021, 10:22 UTC
I'm designing the theming layer for a project built on Bulma and need to pick one customization strategy before the codebase grows. Bulma's documented approach is to override Sass variables such as $primary before importing the framework, which requires a Sass build step and produces a static compiled stylesheet.
The complication is that parts of Bulma's output also reference CSS custom properties, which in principle would allow changing theme values at runtime via JavaScript or :root overrides without recompiling. However, it is unclear how complete that custom-property coverage is across components, and whether depending on it is safe given that the documented, stable API is the Sass layer. Runtime switching (e.g., a user-selectable dark/accent theme) is a hard requirement for us, but so is not forking or patching framework internals.
Assume a current Bulma 1.x release with a Dart Sass build pipeline.
Which components and variables in current Bulma are actually driven by CSS custom properties versus compiled-in Sass values? Is overriding custom properties at runtime a supported, stable extension point, or only the Sass variable API? If runtime switching is required, is the intended pattern multiple compiled stylesheets rather than custom-property mutation?
33775 reputation · 28 Oct 2021, 14:08 UTC
Use multiple compiled stylesheets for runtime theme switching. Bulma 1.x's documented, stable theming API is the Sass variable layer; CSS custom property coverage is partial, undocumented, and not a supported runtime extension point.
Bulma 1.x exposes a subset of design tokens (font family, weight, line-height, border radius, shadows) as --bulma-* custom properties. However, most component styles—buttons, navigation, cards, forms, tables—are authored with compiled Sass values ($primary, $link, $danger, etc.) that resolve to static color values in the output CSS. Changing --bulma-primary at runtime will not recolor a .button.is-primary because that rule uses a hard-coded hex value, not var(--bulma-primary).
The custom properties that do exist are largely limited to typographic and spacing tokens. Color tokens—the most common theme-switching target—are almost entirely absent from the custom property layer.
theme-light.scss, theme-dark.scss).$primary, $dark, $light, $text, $background, etc.) before @use 'bulma'.theme-light.css, theme-dark.css).<link rel="stylesheet"> reference or toggle a data-theme attribute that loads the appropriate bundle via a build-time import map or dynamic import.This keeps you on the supported API, avoids forking Bulma, and gives complete control over every component color.
Before committing, confirm the exact custom property surface in your Bulma version:
# In your project root
npm exec -- sass --load-path=node_modules --style=expanded - <<'SCSS'
@use 'bulma' as *;
@debug 'Custom properties in output:';
SCSS
# Then inspect the compiled CSS for var(--bulma-*) occurrences
grep -n 'var(--bulma-' node_modules/bulma/css/bulma.css || echo 'Check your compiled bundle'
You can also set :root { --bulma-primary: red; } in devtools and observe which elements actually react—expect very few.
Do you need instant client-side switching without a full page reload, or is a navigation-triggered stylesheet swap acceptable? The answer affects whether you preload all theme bundles or load them on demand.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.