View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0022338 | MMW 5 | Skins | public | 2026-09-18 13:47 | 2026-10-22 18:09 |
| Reporter | zvezdan | Assigned To | |||
| Priority | none | Severity | minor | Reproducibility | have not tried |
| Status | assigned | Resolution | open | ||
| Summary | 0022338: Basic skin should use modern CSS color functions instead of LESS functions | ||||
| Description | The newer color functions and relative colors that are relatively recently added to CSS are more powerful than corresponding LESS functions. Most importantly, they are calculated dynamically, during run-time, instead of LESS colors that are static, calculated during compilation to CSS. color-mix - Chrome 111 (https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Values/color_value/color-mix) oklch - Chrome 111 (https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Values/color_value/oklch) using relative colors - https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Colors/Using_relative_colors Most important to me, your interventions with LESS color functions on the basic skin in b3521 causes an error with my skin that previously worked fine. If you have used CSS color functions instead, I wouldn't have this problem. By "basic skin" I mean the skin from the skin folder, not the skins from the skins folder like Material Design. | ||||
| Additional Information | For example, instead of: @controlColor: lighten(@baseColor, 5%); you could write: @controlColor: oklch(from @baseColor calc(l + 0.05) c h); Or, instead of: @disabledColor: fadeout(@textColor, 35%); you could write: @disabledColor: rgb(from @textColor r g b / 0.35); CSS variables are supported by CSS color functions, but not with LESS functions. The next LESS code will cause error: :root { --myColor: @sideBackground; } .verticalPanel .transparentBackground { background-color: fadeout(var(--myColor), @transparentFadeout); } but not this: :root { --myColor: @sideBackground; } .verticalPanel .transparentBackground { background-color: rgb(from var(--myColor) r g b / calc(@transparentFadeout / 100)); } In fact, since the new CSS since Chrome 120 supports nested classes with & selector and > + nesting combinators, it seems there is no need for LESS in MM anymore (https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Nesting). | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
|
|
CSS only implementation sounds tempting, but based on analysis I made, there are some blockers: - Mixins. We use 90 declaration-block mixins (.flex, .textEllipsis, .no-cpu, …) in 228 places. CSS @function returns values, not blocks, and @mixin/@apply isn't shipped. Replacing them would mean utility classes in markup, which breaks third-party skins and addons. - var() can't be used in media-query conditions, and we have two @media (max-width: round(@fontSize*N)) rules (skin_layout, skin_listview). - contrast-color() is Chrome 147, our shipping baseline is still 146, so the 17 contrast() calls would need a workaround for now. Having a complete color computation in runtime would be great though, faster color theme changes, etc. Right now we compile LESS in the renderer and cache it by MD5, so every setLessValues() call — accent colour, font-size multiplier — triggers a full recompile and stylesheet swap (~50-150 ms for the base skin alone); with custom properties that's a single property set on :root. It would also let us drop the hand-rolled colour maths in templates.js (getShiftedRGB and the eight --lvPopup-* variables per popup), and a custom skin could override a token even where the base skin derives it. So my plan would be to convert the variables and colour functions to custom properties while keeping LESS for nesting and mixins. |
|
|
I don't know what you mean by "shipping baseline is still 146". You have 148 in your chromium folder since 3513. Anyway, I replaced in skin_base.less: @textColor: contrast(@baseColor, black, white); with : @textColor: contrast-color(@baseColor); and it works fine; tested with Material Design Orange (dark) and Orange (light). |
|
|
I spoke too early about test. Material Design skin overrides @textColor of basic skin, so it is not using my modification with contrast-color. Just tested Monkey Groove which do not overrides it and got the error because LESS average color function accepts only hex value, RGB value, HSL, or HSV value, i.e. it doesn't accept another function as an argument. Which means all LESS color functions should be replaced, not just single one. By the way, about var() that can't be used in media-query conditions, I think it could be combined with @container queries that accepts var(). For example, instead of: @media only screen and (max-width: round(@fontSize*64.0)) { // } maybe it could be: @media only screen { @container (max-width: round(@fontSize*64.0)) { // } } |