Explore to introduce CSS variables from themes and use in workbench

[bpasero]

It would be useful if we could introduce CSS variables to the workbench from the selected theme so that we can start using the colors in other areas of the workbench.

A quick hack in https://github.com/Microsoft/vscode/blob/master/src/vs/workbench/services/themes/electron-browser/themeService.ts#L361 with

cssRules.push(`:root { --monaco-editor-background: ${background}; }`);

shows that I am able to pick up the color easily:

@aeschli any objections to introduce variables on :root for the colors defined in themes?

[bpasero]

@bgashler1 what are your plans how to compute the right colors for themes other than our default light and dark themes? Are CSS variables powerful enough to compute proper derived colors from the base editor background color?

If we cannot do that with CSS variables, we have to find another solution (LESS?) I guess...

[aeschli]

Using css-variables for color values sounds like a good idea to me. It will help clarify the intend of every color und help us come up with a color system we should use across the workbench.
Colors variables should have names like background_color, input_box_background, search_box_background, primary_foreground, secondary_foreground... (just to illustrate, I make up things here).
I didn't see any color related functions (e.g. darken, lighten, mix) that we can use in css directly but we can do these in code and assign the result to a new variable. What's IMO the most important thing is to come up with a system of colors as described above.

[bpasero]

@aeschli actually the fact that we cannot use calc() with colors worries me a bit. If we end up having to write JS code to compute derived colors from the base colors I wonder if we are not better off using LESS or SASS instead.

When I filed this issue I was not aware that you cannot compute a color from a CSS variable using CSS.

Still interested to hear what Brad has to say (who made this suggestion initially).

[bgashler1]

Moving to SASS is a great idea for a variety of reasons, but in this particular instance, it can't actually help us directly.

The challenge is that these colors need to be changed at run-time based on the theme users have selected; this is where CSS custom properties shine. Except, @bpasero is right that (for now) it's not easy to compute derived colors.

But, there are two possible options to mitigate this:

CSS blend modes

We can still use the CSS custom property base colors. Then we can apply CSS blending modes like mix-blend-mode: soft-light which will take the opaque color and blend it as if had some alpha. This is natively supported in the version of Chromium that we use.

CSS Level 4 color-mod()

CSS Level 4 colors will fix the problem with not being able to derive colors by introducing color-mod() function. This allows you to take a base CSS color and darken/lighten or add alpha.

While I'm not sure if this is currently supported in Chromium, we can use the css-next library, which is comparatively as fast as libsass they say and lets you use CSS 4 syntax today in all browsers. Odds are that we will be able to pull this dependency out soon since W3C is working on standardizing this right now.

[bgashler1]

Here's what using blend-mode: soft-light looks like with multiple themes. It works actually remarkably well at responding to theme (very similar to what we have already).

I have this in a pull request coming up in a minute.

[bpasero]

@bgashler1 I am assuming that we can push this out to the future and we are not blocked currently.

[bgashler1]

@bpasero I wouldn't say we're blocked. The only side-effect of not doing this is that in any other theme but the dark and light, I can't tell what color the editor background is, so our box shadow trick that acts as a gradient mask over text looks more like a shadow.

[Tyriar]

On color-mod, I was just discussing this with @bgashler1. We could mod the color in JavaScript and use additional variables to get around this:

cssRules.push(`:root { --monaco-editor-background: ${background}; }`);
cssRules.push(`:root { --monaco-editor-background-light: ${lighten(background, 20%)}; }`);
cssRules.push(`:root { --monaco-editor-background-dark: ${darken(background, 20%)}; }`);

function lighten(hex, percent) {...}
function darken(hex, percent) {...}

This would save relying on CSS 4.

[bpasero]

Yes, that was my idea as well.

[bgashler1]

We agreed in the UX meeting today to remove the mix-blend-mode and instead use rgba colors to avoid issues with anti-aliasing and other color side-effects that we cannot otherwise work around.

[bpasero]

Sounds good, I will move this to the backlog once we decide how to proceed with general workbench theming.

[nfantone]

Any plans on letting the user use CSS for setting icons (like what Atom does)?

[bgashler1]

I just had an idea related to how we can use the variables approach that @bpasero mentioned above without having to rely in JavaScript to do color adjustments.

We can use something like this...

:root { --monaco-editor-background: ${background};

.someThing {
    /* Overlays the the --monaco-editor-background with 50% white to lighten it up */
    background: (
        rgba(255,255,255,.5),
        var(--monaco-editor-background)
    );
}

This is by no means a substitute for true color transforms enabled by SASS or JavaScript (because it only lets you overlay and not truly lighten or darken). But it's a random idea I had.

[bgashler1]

This color formula also can come in handy as a mixin for SCSS to determine the color that can be used over another color with the greatest transparency possible to equate to a desired color when overlayed.
http://stackoverflow.com/questions/12228548/finding-equivalent-color-with-opacity

[bpasero]

We decided to not go with CSS variables for now.