CSS Variables

[SychO9]

This isn't a proposal to use this feature -yet- but writing down my thoughts on the improvements it can bring and the challenges that come with using it.

---

This feature has been around for quiet some time now, not when most of flarum's frontend design was built though. (https://caniuse.com/css-variables)

Pros

It's very flexible, dark mode for instance would be a simple addition of a class instead of recompiling the CSS.

Using local scoped variables can also solve a lot of problems, clean the code and make it easier to customize.

Instead of using color and background as inline styles for the Tag hero and labels to use the custom color, we should just define a CSS variable inline and let the main CSS code use that, this makes it possible to customize these elements in more ways a lot easier.

For example if I wanted to create a theme where the Tag hero's color is the text color instead, I would have to add custom JS code to get that custom value first, but not if it's define as a CSS variable:

// Before
<header className={'Hero TagHero' + (color ? ' TagHero--colored' : '')}
        style={color ? {color: '#fff', backgroundColor: color} : ''}>
// After
<header className={'Hero TagHero' + (color ? ' TagHero--colored' : '')}
        style={color ? {"--hero-bg": color} : ''}>

// Before
.Hero {
  background: @hero-bg;
  color: @hero-color;
}
// After
.Hero {
  background: var(--hero-bg);
  color: var(--hero-color);
}

Cons

In our codebase, we use some LESS color functions such as fade,lighten,darken,mix ..etc to create color variations. We would have to do something about those if we want to be able to properly make use of this feature and make things like darkmode a simple class change, otherwise while we could still only use it minimally in certain places to improve the code, there wouldn't be much value in using it.

There two approaches I can think of, the second shouldn't even be an option, but I'll mention it nonetheless.

Declaring the variations as variables
Go with a simple approach, which is to define these color variations as CSS variables first, and then make use of them in their respective places. For instance hovering over a primary button shows a darker primary color, in our current code that's darken(fadein(@primary-color, 5%), 5%), we would in that case define (for example) a --color-primary-dark variable with that value and use that.

The problem is with LESS mixins, such as Button--color(@color, @background), it creates variations of the background color, which is more dynamic than color variations created in normal places. We would have to find a compromise between declaring the variation variable and using the mixin.

• Investigate mixins using color variations and combining that with css variables.

Dynamically use variations with hsl by breaking down the colors
Another way which I have tried before in a previous project, would be to break down color variables to 4 variables each, 3 being the hue, saturation and lightness values and the 4th the constructed color value using CSS's vanilla hsl function, then use these values to dynamically create the other color variations. This makes both the compiled code very hard to read and the precompiled code very hard to maintain. We might not even be able to fully recreate these color variations with this solution, and flarum doesn't need these variations to be dynamically created anyway.

[askvortsov1]

I think another important consideration is how we want to implement a system for users to switch between themes. Do we want to take the traditional route of considering light and dark mode to be separate themes? Or should each theme include light and dark mode support?

[SychO9]

I think another important consideration is how we want to implement a system for users to switch between themes. Do we want to take the traditional route of considering light and dark mode to be separate themes? Or should each theme include light and dark mode support?

Not separate themes, just theme settings imho, only issue is how to properly organise these theme settings because we an appearance page in the admin dashboard, a theme should be able to have its own custom appearance settings.

But it would be better to discuss these details in a separate issue, since it is not directly related to the usage of CSS variables.

[tankerkiller125]

In our codebase, we use some LESS color functions such as fade,lighten,darken,mix ..etc to create color variations. We would have to do something about those if we want to be able to properly make use of this feature and make things like darkmode a simple class change, otherwise while we could still only use it minimally in certain places to improve the code, there wouldn't be much value in using it.

Is there any way we could set the LESS variables to the CSS variables (AKA @color-variable = var(--color)) to use those functions? Or does that not work properly.

[SychO9]

Well, LESS doesn't evaluate CSS variables, they are only evaluated by the browser at runtime, and even if it did evaluate them, it would still not really help, we can directly use LESS variables if we want them to be evaluated.

Just need to play with LESS mixins and see if there is a simple solution to have them work nicely with CSS variables, then see if it would be really worth it.