Sass Variable Overrides vs CSS Custom Properties for Bulma Runtime Theming
0 reputation · 12 Apr 2023, 05:00 UTC
0 reputation · 12 Apr 2023, 05:00 UTC
Bulma v1 documents two customization approaches: overriding Sass variables before compilation and overriding CSS custom properties at runtime. A project that needs both structural global changes and dynamic theme switching must decide how to divide responsibility between these layers.
The unresolved behavior concerns the incomplete mapping between Sass variables and CSS custom properties. Bulma derives CSS variables from Sass, but it does not clearly document which variables are exposed. Sass changes are structural and require a rebuild, while CSS variables support dynamic theming without recompilation. Relying only on CSS variables may fail to affect properties computed or hardcoded at build time, while relying only on Sass variables blocks runtime updates.
This creates a trade-off around maintaining parallel customization layers. Duplicating values in both Sass and CSS risks drift, whereas using only one layer may leave certain properties immutable without a full rebuild. The boundary between compile-time and runtime control is version-sensitive and not fully specified; confirming which properties respond to each layer requires practical verification against the compiled output.
Which layer should govern structural tokens like border radius when runtime theme switching is also required? How can a developer determine whether a specific Bulma property is exposed as a CSS custom property without inspecting the generated stylesheet? Is there a documented pattern for preventing value drift across both customization layers?
32775 reputation · 12 Apr 2023, 11:56 UTC
For projects requiring both structural changes and runtime theme switching, Sass variables should govern structural tokens (e.g., border-radius, spacing) and CSS custom properties should govern visual state tokens (e.g., colors, accents).
This division is necessary because Bulma does not map every Sass variable to a CSS custom property. Structural tokens are often compiled into static values during the build process; attempting to override them via CSS variables at runtime will have no effect if the compiled CSS contains hardcoded units rather than var() references.
Since there is no exhaustive documentation for every exposed CSS variable in Bulma v1, you must verify the compiled output. To determine if a property is exposed without manually scanning the entire stylesheet, use the following verification method:
border-radius).var(--variable-name), it is exposed for runtime control. If it is a static value (e.g., 4px), it is a Sass-only token that requires a rebuild to change.To avoid maintaining parallel layers of values, implement a Single Source of Truth pattern. Define your tokens in a dedicated Sass variables file and map them to both the Bulma Sass variables and the :root CSS properties simultaneously.
// _tokens.scss
$my-brand-primary: #00d1b2;
$my-brand-radius: 0.5rem;
// Override Bulma Sass variables (Build-time)
$primary: $my-brand-primary;
$radius: $my-brand-radius;
// Map to CSS Custom Properties (Runtime)
:root {
--primary: #{$my-brand-primary};
--radius: #{$my-brand-radius};
}
This ensures that any change to the token file updates both the structural build and the runtime variables in a single compilation cycle. This approach assumes the use of Bulma v1.0+; earlier versions lack the native CSS variable architecture required for this pattern.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.