Should a Bulma theme rely on Sass variable overrides or CSS custom properties for runtime switching?
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?