Webpack compilation of LESS

DaleZ

I think this change is acceptable. However, it seems that when (@config-dark-mode = true) and fof's Night Mode extension will can't work anymore, and they're valuable.
Maybe consider leafo/lessphp if possible?

SychO

adrianm Another way of going about this, is adding a class to the body or .App element based on the settings and using that to apply the style changes.

This is what we will do with dark vs light mode in 2.0

DaleZ However, it seems that when (@config-dark-mode = true) and fof's Night Mode extension will can't work anymore, and they're valuable.

In 2.0 dark v light mode will have a clear class in the body so what was:

when (@config-dark-mode = true) {
  ...
}

// would become in 2.0
.dark {
  ...
}

fof's Night Mode will likely no longer we necessary since Flarum will be easily able to provide user light/dark switching.

The only real challenge I have run into so far, is the color functions. The primary color is configurable and since 1.x parses LESS on the backend, operations like these are possible:

  --body-bg:                       @body-bg;
  --body-bg-shaded:                darken(@body-bg, 3%);
  --body-bg-light:                 lighten(@body-bg, 5%);
  --body-bg-faded:                 fade(@body-bg, 93%);
  --text-color:                    @text-color;
  --link-color:                    @link-color;
  --heading-color:                 @heading-color;

  --muted-color:                   @muted-color;
  --muted-color-light:             lighten(@muted-color, 10%);
  --muted-color-dark:              darken(@muted-color, 50%);
  --muted-more-color:              @muted-more-color;

  --shadow-color:                  @shadow-color;

  --control-bg:                    @control-bg;
  --control-bg-light:              lighten(@control-bg, 3%);
  --control-bg-shaded:             darken(@control-bg, 4%);

2.0 would still need to support such color operations somehow 🤔

DaleZ

SychO In 2.0 dark v light mode will have a clear class in the body

Glad to hear that we'll have the native way without an extension 🙂

SychO The library seems to have been updated in the past year, so we could also not go through with this change, at the expense of having the same issues with it in another future.

So...

DaleZ Maybe consider leafo/lessphp if possible?

luceos

SychO 2.0 would still need to support such color operations somehow

Aren't there webpack helpers for that?

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

luceos they wouldn't work with colors that are configurable like the primary color, the CSS will have already been compiled by then.

Only way is to add the ability to use color functions that we parse in the backend $lighten(--primary-color, 25)

luceos

SychO feels like we are losing massively on flexibility here. An ondemand parser should still be possible, and I was assuming that would be the case. Can you clarify how this would work from a technical standpoint? I'm available for a quick call the coming week if that helps.

Darkle

SychO Wouldn't PostCSS fit well with the colour-function plugin (postcss/postcss-color-function)? I haven't slept much, so don't pay too much attention to me...

SychO

luceos An ondemand parser should still be possible, and I was assuming that would be the case.

Moving from backend less to webpack less essentially means that's not the case. The Less package had not been updated for a long time (flarum/issue-archiveissues/4), leading to deprecations (that would turn to errors in the future) and inability to update some libs like font awesome to v6.

The library seems to have been updated in the past year, so we could also not go through with this change, at the expense of having the same issues/situation with it in another future.

luceos Can you clarify how this would work from a technical standpoint?

which part?

I'm currently weighing how doable the color functions would be to create parsing for them on the backend, depending on that it'll be clear whether this can move forward technically or not.

SychO

DaleZ leafo/lessphp

leafo/lessphp has not been updated in 6 years so it's not an option.

DaleZ

SychO I was cheated by that Github repo because it looks like "new" 😂

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.

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