Code change:
When running VS Code (or the Monaco editor) all theme colors are exposed as CSS variables. That means components don’t need to use JavaScript to read and set colors but can simply rely on CSS. When a theme changes, the variable values automatically update. Also, with CSS variables you have less code and everything in one place. The (long) list below is all users of . Those that only set/update colors are candidates for adopting CSS variables The names of the CSS variables can be "derived" with the following logic the theme color id and replace dots with slashes For instance the color id is exposed as CSS variables . Find a sample adoption in this commit: [ ] [ ] [x] [x] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x]
Hi, is this issue still up for grabs? I would like to be assigned to one of the bullets.
Yep! Just feel free to grab whichever one you want and open a PR for it :)
Hi! I would like to grab
Hi How did you linked your PR in every line of the description in this issue? I am not able to edit the description and I opened a PR for 12 hours ago. I guess edited the description to add your PR but not mine?
Maybe I mentioned this issue in the pr?
Yes, I was just wondering if there was an automated way of doing this, but I dont think so. Thank you!
I wrote a small helper that generates dynamic CSS rules but with the css variables filled in: You can use this for simple cases. Hopefully, it prevents some typos. The code is at:
Terminal is done, the following are intentional exceptions: We need to pull the color into TS to pass to as it uses it in canvas calls. We need to apply 0.5 opacity to the resolved color for the background, using won't work as it will fade the text.
Tunnel view, comments, and tree view are done.
what is the recommendation when more than the color is part of a ? To give an example: Here, we conditionally make an element if we have a . We cannot just blindly move that over to CSS because we then lose the check for the color.
I don't know. Has to stay in code....
can I listen to a change for a color key via theme service to conditionally toggle a class based on a color being defined or not?
Yes, and
If anyone else is still working on this, you can get completions with this handy extension
What is the recommendation if I have to hardcode a codicon css, for eg., I am deriving the codicon class programatically as follows If I have to move this to CSS then I have to hardcode the codicon class as follows Is it ok to hardcode codicons like this?
Looking at where verifiedPublisherThemeIcon is used, it's always in a dom node that also has the class . Better avoid the codicon class name, but use
Interesting issue where a migration to CSS variable caused a bug (). It looks like some visual behaviour is defined by the OS/runtime and not by default user agent CSS to fallback to. So if your CSS variable ends up as , you get some default (?) and the result is that the OS styling is disabled. Relevant SO for my case:
I looked over mine again and they are all there still intentionally: I don't think we can get the same effect of in CSS using the variable. Same as above. This is needed as the color is handed off to
please check those occurrences anyways so that we can remove them from the todo list
For , I couldn't find references to . For , we use the RGB values from the foreground var and we use a custom alpha. Since this only applies to the text, I don't think that there's a CSS-only equivalent. We could create a new var for this or just leave this as is; I'm not sure what's best in this case.
you're setting there so you can probably use a plain style, unless the element also has a background color as that would also apply there.
The element also has links, which have a normal alpha, so then the link opacity is affected.
you could have another rule with higher specificity that re-applies the link color?
For you could define a new (terminal hover specific) color. The default value of the color can express that it is a function of To access a color value use
As discussed in standup, tabs have quite an involved CSS ruling that involves not only colors but also other properties. I would like to keep it this way via and not invent various class names to get a similar effect to make maintenance easier there.
Closing this as I believe we are done here

Related discussion:
text: this._domNode.title = value; } } <del> registerThemingParticipant((theme: IColorTheme, collector: ICssStyleCollector) => { const editorBackgroundColor = theme.getColor(editorBackground)?.transparent(0.7); // Lightbulb Icon const editorLightBulbForegroundColor = theme.getColor(editorLightBulbForeground); if (editorLightBulbForegroundColor) { collector.addRule(` .monaco-editor .contentWidgets ${Codicon.lightBulb.cssSelector} { color: ${editorLightBulbForegroundColor}; background-color: ${editorBackgroundColor}; }`); } // Lightbulb Auto Fix Icon const editorLightBulbAutoFixForegroundColor = theme.getColor(editorLightBulbAutoFixForeground); if (editorLightBulbAutoFixForegroundColor) { collector.addRule(` .monaco-editor .contentWidgets ${Codicon.lightbulbAutofix.cssSelector} { color: ${editorLightBulbAutoFixForegroundColor}; background-color: ${editorBackgroundColor}; }`); } }); </del>