Drop Less in favor of modern CSS

[craxal]

Less is a CSS pre-processor that makes working with styles a lot easier. The most notable features we use include:

• Variables
• Parent selectors &
• @import rules

CSS has evolved over the years, overcoming many of the pains of working with plain CSS:

• CSS variables/custom properties (already in use for theme colors)
• Nested rules
• @import

A Less sample:

@import (less) "./SharedStyles.css"

@themeColor = #123456;

.grid {
    background: @themeColor;
    display: grid;
    grid-template-columns: auto 1fr;

    .name {
        grid-column: ~"1 / 2";
    }

    .data {
        grid-column: ~"2 / 3";
    }
}

An equivalent modern CSS sample:

@import url("./SharedStyles.css");

:root {
    --themeColor = #123456;
}

.grid {
    background: var(--themeColor);
    display: grid;
    grid-template-columns: auto 1fr;

    .name {
        grid-column: 1 / 2;
    }

    .data {
        grid-column: 2 / 3;
    }
}

Full support for these features is available as of Electron 28 (Chromium 120). I've been able to confirm that these features work in my own experiments using Electron 28.

Less comes with a few downsides:

• Compiling Less files can be time consuming for the build. For example, Standalone takes 7-8 seconds to compile, which adds up quickly over many iterations.
• Debugging generated CSS styles and tracing them back to the original Less declarations can also be cumbersome.
• Compiling more modern CSS syntaxes can lead to subtle issues that require workarounds. For example, grid-column: 1 / 3 is interpreted as math in Less and is compiled incorrectly unless it is written as grid-column: ~"1 / 3".

Switching to modern CSS can save on build time, debugging time, and maintenance costs. The switch can be done gradually over time. Modern CSS can import other CSS files, so styles generated from Less can continue to be used during a migration period. Native CSS can also be declared in HTML, potentially reducing the number of files needed.

[MRayermannMSFT]

Please spend 1-3 days during further investigation. Including resolving some open questions ideas including:

• What changes need to be made to existing build scripts to allow .css and .less files to exist side by side in the same component/Standalone?
• Can we use an automated tool (such as the less compiler or something else) to automatically convert all of our .less to modern .css?

[craxal]

What changes need to be made to existing build scripts to allow .css and .less files to exist side by side in the same component/Standalone?

Virtually nothing. Less files can continue to be compiled, which will produce generated CSS files. All we really need is to add a build task that copies authored CSS files to the output directory like any other static file (like HTML or SVG). The only thing to keep in mind is CSS files will need to refer to generated CSS file paths.

Can we use an automated tool (such as the less compiler or something else) to automatically convert all of our .less to modern .css?

Ironically, Less would be the ideal tool for this. Unfortunately, Less does not currently support CSS nesting, and it's not clear when/if they will.

However, the syntax is so similar that converting Less to CSS wouldn't be hard to do by hand. We're not using too many fancy Less features, so most of our existing Less files could be converted with virtually no editing. And the fact that they can both import means conversion doesn't have to be done all at once.

[craxal]

Some build script updates need to be made for some light CSS processing. This is because compiled files have different paths than source files. Thus, paths in source CSS (via @import url(...)) are very likely to become inaccurate without some processing. Common places where this happens include:

• Packages where Less references style files from other modules (through node_modules)
• Standalone where the output files end up in a directory one level deeper than the source.

Fortunately, esbuild can handle this for us. Instead of passing Less files to the Less compiler, we can simply pass entry point CSS files to esbuild, which will bundle source CSS files together with their imports into one CSS output. This does mean we lose out a bit on build output size, as shared styles will be duplicated in the output for each entry point, but I don't think this contributes much to the output size overall.