Webpack compilation of LESS

askvortsov

Between hsl, calc, and color-mix, can't we get a decent portion of the way there through native css?

Did we consider encouraging use of prefers-color-scheme instead of a dark class?

SychO

askvortsov color-mix

Oh color mix is interesting, didn't know it existed. Will check it out.

askvortsov Did we consider encouraging use of prefers-color-scheme instead of a dark class?

We would have to use both. The class is so that we can easily switch between light and dark. The prefers color scheme is to determine the default state (will be used on the js side)

If we directly use prefers color scheme in css then we can't switch.

adrianm

SychO

Yeah cool I actually think native CSS might be able to handle what I was after anyway - as others have mentioned. I'll see if I can get a quick POC of a really basic theme switch (light, dark, etc) using native CSS through the week.

SychO

After working on a separate PR to get back insight on what color manipulations we do and how we do them before getting back to this issue here. I believe the best course of action is to not do this at this time.

There is definitely a way not to need LESS color functions, by breaking down colors into 3 values for HSL, but having done that in the past, it makes the code hard to work with.

The best would be to use the new CSS color functions that support relative changes, mainly hsl, color and color-mix, but the browser support for these is just not there yet, I reckon in 2 - 3 years it might be in a good place, so this is likely something for v3.

For reference:

Example
using darken(@primary-color, 5%) in less would be equivalent to using the CSS function:
hsl(from var(--primary-color) h s calc(l - 5))

So for now we might just stay on the current backend LESS parsing, until browser support for the new color operations is in a better stage.

rob006

SychO There is definitely a way not to need LESS color functions, by breaking down colors into 3 values for HSL, but having done that in the past, it makes the code hard to work with.

What exactly was hard in that case? I though that having set of predefined colors based on primary/secondary forum color would make things easier, and layout will be more consistent, as extensions would not create 50 shades of the same color.

SychO

rob006 code readability was horrible with that method. Maintenance was a lot more difficult as well because of that.

rob006

SychO Do you have an example? For me styles like

.my-button {
    background-color: var(--primary-color);
    color: var(--primary-color-light-3);
}

are more readable than some manual color calculations using less.

SychO

rob006 I don't think we are talking about the same thing. That's already what we do in core. We define the color variations as css variables and use those css variables elsewhere.

I was specifically talking about having to breakdown each color into an h, s and l value to be able to apply dynamic color variations using the css hsl function.

Something like:

--primary-color-h: 20;
--primary-color-s: 20;
--primary-color-l: 20;
--primary-color: hsl(var(--primary-color-h), var(--primary-color-s), var(--primary-color-l));

--primary-color-dark-1: hsl(var(--primary-color-h), var(--primary-color-s), var(--primary-color-l) - 5);

rob006

SychO I was specifically talking about having to breakdown each color into an h, s and l value to be able to apply dynamic color variations using the css hsl function.

And my question is: why would you need this? For me forum should have a closed color palette based on forum settings, and extensions should use these predefined colors instead of generating its own slightly different shades. You don't need less then, colors could be calculated at PHP level by Flarum and registered as CSS variables. In most cases this should simplify styling, if Flarum provides pairs of color and background-color values with correct contrast - as an extension developer you don't need think about it anymore, you just pick background color for your element and text color is already predefined. And for edge cases extensions still should be able to calculate its own colors at PHP level and register them in the same way as core does.

SychO

rob006 moving the current color operations which can be very nested (color1 = darker primary, color2 = mix of color1 with colorx, color3 = lighter color2 mixed with ..etc) to the php side would be really not be ideal. It's also less flexible if you have to register a css color outside the css code. I'd prefer the current flexibility with backend less parsing over that.

Also, extensions can use current defined color palette, but they should continue being able to define further shades.

« Previous Page