Impossible to use customize CSS variables due to HSL system

[darkylmnx]

This is about Bulma.
It's a bug or design issue/discussion.

Overview of the problem

This is about the Bulma CSS framework.
I'm using Bulma version 1.
I am sure this issue is not a duplicate.

Description

When using CSS variables, if I want to change the primary color of
everything with --bulma-primary it actually doesn't work.

All comes down to the HSL thing and the fact the each components users CSS variables in a confusing way.

Using HSL is not a choice I'd have made for color management, but that's just personnal and is not really the issue.
The main issue is that HSL is forced and can't be overwritten.

For example --bulma-primary is actually never really used, so changing it doesn't really do anything.
Lets take .tag as an example at line : https://github.com/jgthms/bulma/blob/main/css/bulma.css#L5110
For a confusing reason, the primary tag doesn't use --bulma-primary but redefines a background-l:

• https://github.com/jgthms/bulma/blob/main/css/bulma.css#L5113
• https://github.com/jgthms/bulma/blob/main/css/bulma.css#L5121
• https://github.com/jgthms/bulma/blob/main/css/bulma.css#L5190

That is very confusing and this level of granularity actually makes it not very flexible.
The whole goal of "primary, danger, success" are that it's "the same" everywhere.
It's really confusing that it's redefined based on a granular rules and not the --bulma-primary.

In terms of bundle size, it makes things even worse.

If .tag only had background-color: var(--bulma-background) and then .tag.is-primary only redefined background-color: var(--bulma-primary), customization would be less confusing, faster to setup, and less bundle size because no need for unecessary granular variables that only less then 0.1% people would need.

Weirdly .button.is-primary works the same way but for .button.is-primary[disabled] you used the global --bulma-primary which makes it even more confusing: https://github.com/jgthms/bulma/blob/main/css/bulma.css#L3599

The chances that people would want to change the HSL values independently but not want to use the global value (which is actually use almost nowhere) doesn't really makes sens, especially when all ".is-primary" elements are supposed to have the same color.

Steps to Reproduce

Just a regular install and customize --bulma-primary on the frontend.
Here's a JSFiddle to demonstrate: https://jsfiddle.net/3s1u7Ln5/

Expected behavior

Expect to change --bulma-[primary|success|etc] and have derived usage inherit from it and not having to set up
each HSL independently.

It's especially a pain in the ass when modifying the theme through JS based on user input.

If not I don't even se why --bulma-[primary|success|etc] exist in the first place, if you only use the HSL variables independently.

Actual behavior

Explained above.

Just to be clear, I really appreciate the work done here, i'm not blaming or anything, just saying that all this makes customization very hard.

I'm open to any idea/solution.

[digitigradeit]

Let's break it down.

Bulma's --bulma-primary custom property serves as a foundational color, influencing various components throughout the framework. This property is defined as individual HSL values which correlate each to their own custom properties as well.

To make it even more interesting, an entire palette of colors based on the original primary color is also generated. And each one of these colors also has customizable variables for their properties. So when you include is-primary is-info is-link each are all based on their own individual custom properties which allows for further customizations.

Now, you can tweak this primary color by adjusting its individual components (H, S, L) or by directly modifying the --bulma-primary property itself. Example:

https://jsfiddle.net/vu7rbL1g/

But you will quickly find it doesn't propagate because the color scheme is generated based on the original turquoise green color. The pre-built CSS is based on colors defined here: https://bulma.io/documentation/features/color-palettes/

However, diving into the nitty-gritty of customizing these colors using plain CSS can get messy. Sure, you can manually adjust the H, S, and L values, but it's far more convenient to handle these changes with SCSS. Here's an example of how you mgiht go about this:

:root {
  --bulma-primary: rgb(0,0,255);
  --bulma-primary-h: 240;
  --bulma-primary-s: 100%;
  --bulma-primary-l: 50%;
  --bulma-primary-invert-l: 100%;
 }

Or: https://jsfiddle.net/L0enf8oh/

Now with SASS/SCSS, you can swiftly update the primary variable and the framework will take the color automatically convert to its HSL equivalent and then generate teh scheme based on that. and let it cascade down to all related components, saving you a ton of time and effort.

Example:

@use "..//node_modules/bulma/sass/utilities/derived-variables" as dv with ($primary: rgb(0,0,255),);

TLDR: While it's technically possible to tweak Bulma's colors using pure CSS, but it's a helluva lot easier with SCSS/SASS.

As for your example with the buttons, you're spot on about the complexity. Changing the color of a button involves a dance of various interconnected variables, like --bulma-button-h and --bulma-button-color-l, which derive from the primary color or whichever color you pick for that button.

In the provided example you're trying to customize the color of the default button, rather than a primary colored button.

So, if you're diving into Bulma customization, consider embracing SASS/SCSS. I think it'll save you a lot of time, headache, and heartache! :)

(no need to use javascript btw, css is fine just either attach them to the relevant selector for that component or attach them to :root directly. either way, I always consider customizing via css variables more of a last resort.

[digitigradeit]

This is just one (of many) example on how to customize the color of buttons:

:root {
  --custom-button-1-h: 240;
  --custom-button-2-h: 100;
}

.button.is-custom-1 {
  --bulma-button-h: var(--custom-button-1-h);
}

.button.is-custom-2 {
  --bulma-button-h: var(--custom-button-2-h);
}

<button class="button is-primary">Primary Button</button>
<button class="button is-custom-1">Button Custom #1</button>
<button class="button is-custom-2">Button Custom #2</button>

[darkylmnx]

but it's far more convenient to handle these changes with SCSS
and let it cascade down to all related components, saving you a ton of time and effort.

That's the whole point, the goal is to not have to use SCSS, because in many cases you can't.
For example, when you're creating an editor where the end users can choose their own colors (form, CMS, embeds, video player...).

Having to change each H, S, L property individually when there's suppose to be a common property aggregating `--bulma-primary', makes it harder to think about and harder to customize.

(no need to use javascript btw, css is fine just either attach them to the relevant selector for that component or attach them to :root directly. either way, I always consider customizing via css variables more of a last resort.

If I used JavaScript for my example, it's because it's the most granular example which englobes when the customization is not a static, but a dynamic.

If you consider customizing through CSS as a last resort, it means you never needed it in the first place.

The CSS variables serves only one main purpose if you already use a preprocessor:

• Customizing dynamically in the browser without having to override properties

If there's no CSS variables, handling dark mode or "themes" on a page needs to override too many selectors.
If there's no CSS variables, handling custom CSS based on user input could need to save the user input in the backend, and generate a CSS file for each use with a SASS/SCSS server/service.

When you have like a few hundred users, it's ok.
When you have thousands of users, if becomes a file/caching/cost nightmare.

With CSS variables, you don't need that anymore as you can generate the custom values on the fly.

But with how this is setup here, it makes things very hard.

[darkylmnx]

To make it even more interesting, an entire palette of colors based on the original primary color is also generated

What you're describing also exist on Bootstrap in their own way and it's done in a bit more straightforward way.
https://getbootstrap.com/docs/5.3/customize/color/

Same for the variables: https://getbootstrap.com/docs/5.3/customize/css-variables/#root-variables

I prefer bulma's class naming and general philosophy but the actual system is making things very hard to customize.

[digitigradeit]

That's the whole point, the goal is to not have to use SCSS, because in many cases you can't. For example, when you're creating an editor where the end users can choose their own colors (form, CMS, embeds, video player...).

Sorry, there appears to be a disconnect at least, I'm not seeing the issue. You can run dart-sass locally and create your own CSS file which you can then either check into git and then using something like jsdelivr you can serve the css file straight out of your GitHub repo.

Having to change each H, S, L property individually when there's suppose to be a common property aggregating `--bulma-primary', makes it harder to think about and harder to customize.

it does make it significantly harder, but the lightness component in HSL will apply to other parts of that component/element (i.e. button's hover/active border, or the background-color on hover, etc). these are just examples.

If I used JavaScript for my example, it's because it's the most granular example which englobes when the customization is not a static, but a dynamic.

but in the provided example there was some javascript attempt to change the custom css properties. while it might have worked, I'm not sure I understand why you would do this in any service offering.

And you missed the point about the buttons you were customizing are defined without a color in teh first place. that's a different set of variables.

There is something else you are completely overlooking. The concept of themes, and light and dark modes. This is where there broken out components to the HSL color values comes into play especially. Yes, you are absolutely right it's' almost like learning a new programming language. I still havent' rolled out bulma 1.0 on my personal site becasue I'm still tinkering with it.

If you consider customizing through CSS as a last resort, it means you never needed it in the first place.

Please don't take my comment out of context. I did not say customizing through CSS was a last resort. I said customizing through css variables (really what I meant was CSS custom properties) is a last resort on my part. My project uses SCSS and I'm perfectly fine with that. I can adjust the $primary variable and I dont' even need to thikn about it.

The CSS variables serves only one main purpose if you already use a preprocessor:
Customizing dynamically in the browser without having to override properties

Why would you do this? What is the use case and example? If you are looking to do this dynamically it really leads me to believe that you are not really leveraging the frameworks' full potential i.e. using button states for hover, disabled, active, etc by simply changing a delta custom property.

If there's no CSS variables, handling dark mode or "themes" on a page needs to override too many selectors. If there's no CSS variables, handling custom CSS based on user input could need to save the user input in the backend, and generate a CSS file for each use with a SASS/SCSS server/service.

I honesly cannot imagine implementing a "theme" without using SCSS. If you are not able to use SCSS in your build process for whatever it is, then I woudl reach out for help on what ever it is you're trying to do/achieve, rather than pointing out potential flaws in the framework because it's "too difficult".

You can use the :root {} selector, or apply all the navbar-related custom properties to .navbar {} in your css file. this really isn't that complicated.

Yes, the upgrade was a HUGE fucking update. But, also, let's be real people it is a beta release... use an older version of Bulma if it works the way you want, but please dont argue unnecessary complexity when describing production scenarios like form, CMS, embeds, video player.

When you have like a few hundred users, it's ok. When you have thousands of users, if becomes a file/caching/cost nightmare.

What service are you speaking of? Are you talking about a hypothetical situation? or an active service.

With CSS variables, you don't need that anymore as you can generate the custom values on the fly.
But with how this is setup here, it makes things very hard.

Nothing is preventing you from using an older version of bulma until the new version is more mature. Also no one is forcing you to use the new version either. So I'm not sure how else to help. I provided some examples, which you seemingly didn't' even acknowledge.

But where I really have to take a stand and defend the framework is that is that there are no custom css properties in previous versions, so what's the hang up? What exactly is your issue? I provided examples on how you can go about doing what you asked which seem to have been completely ignored. If you like Bootstrap's custom property implementation better. Nothing's stopping you from using that.

[darkylmnx]

@digitigradeit Man, I'm not gonna argue with you. If you don't see the problem, just pass your way.
If HSL in this current state works for your, then great.

Let Thomas give his stand on this, I don't really need your agressive input.

[digitigradeit]

There was no aggression, perhaps you were being a little aggressive coming at me, someone who literally just tried to help you, not only that, I provided examples with working code. We can agree to disagree, but damn, entitled much?

[darkylmnx]

There was no aggression, perhaps you were being a little aggressive coming at me, someone who literally just tried to help you, not only that, I provided examples with working code. We can agree to disagree, but damn, entitled much?

1. never was agressive, I guess that's just a matter of perception in both ways
2. you're saying you tried to help, no worries on that, you didn't read the post enough before replying tho, your code example is literally what I put in my JSfiddle so helping on what? I don't really see how
3. it's not a technical problem, I know how to change HSL, I did prove it in my JSfildde, again, it's an ideology and design issue where creating a global variable that holds sub variables confuses things because the global variable would be used almost nowhere. The whole conversation is about that, but your answers are not relevant to that as you're answering as if I don't know how to do basic CSS when I literally showed in the JSfiddle what my issue is with the design
4. Entitled by what? You don't seem to see the issue maybe because you don't create apps like the types of app I do, that's not a problem but arguing in long posts to explain basic CSS which isn't the issue at all and saying things like:

no need to use javascript btw

Definitely shows you didn't understand my issue and is literally trying to say:

hey newbie, that's how we use CSS variables

When, in my case, for live customization in an editor or whatever similar scenario, JS is needed for live/client-side previews, and I literally explained that by saying "It's especially a pain in the ass when modifying the theme through JS based on user input.".

Anyway, you're saying i'm entitled when you didn't read the issue properly IMO and are patronizing, so please, look at what you did first.

In any case, THANK YOU if that's what you're waiting for, but, my issue is not about writing basic CSS.