[themes] Themes don't support background styling

[Tyriar]

.tmTheme files allow specification of background colors which don't seem to be supported, for example:

<dict>
  <key>name</key>
  <string>Separator</string>
  <key>scope</key>
  <string>meta.separator</string>
  <key>settings</key>
  <dict>
    <key>background</key>
    <string>#E0E0E0</string>
    <key>foreground</key>
    <string>#373B41</string>
  </dict>
</dict>

This is especially problematic for themes that attempt to invert background and use a similar foreground to the text view's background color (https://github.com/Microsoft/vscode/issues/2158)

[mtd91429]

+1

[kanlukasz]

+1

If you want to vote, simply add 👍 in the first post. In this way, they set priorities for future functions It's better than creating another +1 post

By the way, "VSCode Dev Team" I'm begging you to implement it. It's REALLY useful! We all wait for it

[Zireael]

Please add [background] styling

[ghost]

Is there at least a work around for accomplishing this?

[NetVicious]

Is there at least a work around for accomplishing this? No. There it's no workaround to get that at this moment. That's the main objective of this feature-request.

[ghost]

@NetVicious there is a work around I found - you can just use text decorations. Not exactly ideal, but it works well enough.

[romanhaa]

@NetVicious there is a work around I found - you can just use text decorations. Not exactly ideal, but it works well enough.

That looks pretty neat actually. Do you mind sharing how you did that?

[kanlukasz]

That looks pretty neat actually. Do you mind sharing how you did that?

@daniglas I am also very curious!

[ghost]

Sure thing:

Basically this is 1 language with 2 embedded languages. Sql is blue and Groovy is red.

I wrote a set of regular expressions to return sql and groovy vscode.Range(s) based on the brackets you can see in the picture(Sql [], Groovy [[]]). Ranges are updated via onDidTextDocumentChange event. Once I have the ranges, I can make a call to vscode.window.activeTextEditor.setDecorations(, ranges). This call is made every time the event onDidTextDocumentChange occurs(after range update above). My sql decoration object is initialized like this:

this.sqlLanguageContextDecoration = vscode.window.createTextEditorDecorationType({

        overviewRulerLane: vscode.OverviewRulerLane.Right,
        isWholeLine: true,

        light: {
            overviewRulerColor: 'rgba(0,150,225,1)',
            backgroundColor: "rgba(0,150,225,0.15)"
        },
        dark: {
            overviewRulerColor: 'rgba(0,80,180,1)',
            backgroundColor: "rgba(0,80,180,.15)"
        }

    });

The syntax highlighting for the sql and groovy contexts occurs in the tmLanguage.json file. If you are curious how that is implemented, let me know!

[NetVicious]

@daniglas Hi! Can you explain us a bit more how to add those extra settings to VSCode? Which files we need to edit and where to place those settings you pasted.

I found this sample extension and it seems you're doing something similar to it: https://github.com/microsoft/vscode-extension-samples/tree/master/decorator-sample

Regards,

[internetimagery]

+1

[runxel]

Somewhere in this thread it's mentioned there would be problems when text with background is selected. However since nearly every other editor in existence supports background styling this can't be too hard. E.g. the simplest solution would be just to drop any other background styling when selecting text. This is how Sublime Text does it, I think.

[saioacoder]

This is how it looks the theme that I use in Atom, and I am very disappointed that I can't get that with VSCode. This kind of customization allows a more subtle and smooth syntax design, because I don't like aggressive designs with saturated colors.

I would love to switch, because I like how VSCode works but I need this feature, it seems very basic to be able to do it. :((((

[internetimagery]

That style, in Atom has the selection padded a couple pixels larger than the highlighted background (or I guess the background is smaller than selection).

[chavlji]

4 years and still going... :(

It's extremely useful for numerous reasons:

• Having textual files (md, txt,...) with white background, while code files have black background
• Files with mixed languages (html, vue, php,...) have sections with different backgrounds
• Important things (h1 in md, flow changers,...) are emphasized

I'm begging you to add this!

[jportoles]

+1 Files with multiple embedded languages in them would benefit enormously from having sightly different background colors. It improves readability and makes it easier to switch between contexts.

[GotJimmy]

I'm using the "Highlight" extension in VSCode to get certain parts of the code to have different background colors and/or decorations. All you need to do is use regex and CSS to accomplish this. Nice hack but official background color support would be better!

[Eugleo]

Any plans to do this? Or any way an outsider can help?

[woody77]

With the addition of semantic highlighting, this is even more useful, as now LSPs can apply modifiers that can be picked up by themes to explicitly color the background. Examples:

• comments (doc vs. inline)
• return points (for languages that support multiple return points)
• Rust's unsafe
• de-activated code (VSCode already does this natively for C/C++ with a drop in opacity, but it would be great for other languages.
• any async (Rust) or similar sort of closure that will be executed "later", and not inline

And if they exposed to the VSCode theming system, which also controls selection highlights, search highlights, etc, it should be possible for a theme designer to make this all work together as they desire (and then it's also overridable by individual users using settings.json and semanticTokenColorCustomizations

[mika76]

Also keen on this feature. It's really sad it actually works and is just turned off. Can't a priority route just be picked of give us a setting in the color syntax definition to set which background has priority or something. It seems to me a lot of people want this feature so why ignore it?

[Quest79]

Between this, File Explorer getting 'Sets', and better bookmark management in Chrome, I cant decide what I want more that devs just dont' want to add even though the code is basically done.

Please?

[woody77]

Having spent some time trying to create a theme from scratch, I better understand what the complication is, but I still think it should be added. There are a LOT of background color interactions already, and it takes a bit of trial and error to figure out how they'll play together.

Some better documentation around the precedence/order that theme categories are applied would help both theme developers, and I think extension developers as well, understand what's going on.

[NetVicious]

I don't understand yet why this feature was disabled time ago. If the background theming it's only for the editing window this feature won't bother anything because If I enable one theme which doesn't leaves me to read correctly my code I will change it for the previous one, and I will delete it, full stop. If the problem it's a theme can change the background of the menus and make they not readable, this problem can be easily fixed showing a simple window with a sample menu with the colors of the new theme or a simple window asking if the user can read all correctly, something like windows does when you change resolution of the screen. If you press No they previous theme will be loaded another time....

[lignumaqua]

I'm using the "Highlight" extension in VSCode to get certain parts of the code to have different background colors and/or decorations. All you need to do is use regex and CSS to accomplish this. Nice hack but official background color support would be better!

Thanks for the suggestion, this works well. I also found that if you keep the alpha of the background highlighting low (0.2 or 0.1) then it plays well with with VSCode's native use of background colors.

[kanlukasz]

In two months, it will be five years from this request. Can't you really make this feature available since it was once available? It doesn't have to be active by default. Give us a choice, please

[runxel]

Even funnier that there is now background styling – but just for errors... So this feature can't be that hard after all.

[nahuel]

In Emacs you can style the background color, is very useful to make top level definitions visually prominent by inverting them. If you select the styled text, then his background color is replaced and the foreground color is changed to contrast with the new one (no alpha blending powers are used!). This is no problem at all, because most of the time you are reading, not selecting. Check this screenshot:

[katerlouis]

You might laugh, but this is one of two major reasons why I'm still using SublimeText... The other being "search & replace".

What do we have to do? :D

[richardtallent]

Just ran into this today... I'm replacing ACE Editor with Monaco. The "language" we're writing is a custom, in-house DSL, so it's not even a programming language, just marked-up text with special headers, errors, etc. Background colors are fairly useful for calling the user's attention and dividing what is otherwise monospaced text, so I'm sad to have to remove that feature, since otherwise Monaco is pretty darned awesome.

Or, just give us actual CSS classes based on token names instead of this "mtkXX" stuff and we can do it ourselves...

[zetashift]

Would love to see this in too! Especially handy for Markdown code blocks.

[HTGAzureX1212]

Just ran into this today - would really like to see this implemented so that some specific keywords in a programming language can be highlighted with a background colour:

[marcoscannabrava]

I just ran into this SO Answer suggesting the highlight extension.

A hacky workaround for something that could be native IMHO but it does the job :+1:

example:

"highlight.regexes": {
  "(//TODO)(:)": [ // A regex will be created from this string, don't forget to double escape it
    { "color": "yellow" }, // Decoration options to apply to the first capturing group, in this case "//TODO"
    { "color": "red" } // Decoration options to apply to the second capturing group, in this case ":"
  ]
}

[pouyakary]

Just as a reminder, I wanted to highlight the fact that inlay hints are a very great example of:

1. How great token background colors do look in the vs code
2. They can co-exist with selection color and ...
3. The VS Code team itself believes its possible to have token background colors which makes this argument no longer valid:

   We had it in, but turned it off as it conflicted badly with the other background decorations we have (selection, word highlighting). — @aeschli

I really think that it becomes the responsibility of the theme author. We can as well set the token colors to the background color of the editor and make the text invisible. But then the user downloads and tries the theme and when they see that issues like these exists, then they go for another theme and write a bad review. VS Code provides almost 100% freedom on what can be accomplished in an extension right now. One has access to the node modules, can create custom editors, can load any binary inside of it, I mean the possibilities are limitless. @Tyriar even made a paint in code! So why when almost everything is possible, limit this one?

Please give this idea another shot. I personally have waited five years for this and came back to it times and time. So imagine how much I personally appreciate it, and I think rest of the community maybe with me on this that they are too are still (after five years) asking you.

[katerlouis]

Is there really no way to write an extension that adds this feature?

[Quest79]

Its hilarious how long this has been here. A basic feature of any modern programming UX refused to be added.

What will be forgotten next? Ability to change fonts? Color? Lets all go back to notepad.

[pouyakary]

What I don't understand is that why they have kept the issue open. Okay if five years of talking won't convince you then what will? I hate to have my hopes up five years for something no one is going to give any notice. At least close this so we all know once and for all that okay you won't.

[shot-codes]

Oh, this thread is depressing :(

[pouyakary]

GitHub seems to need the "😭" reaction too...

[NetVicious]

What I don't understand is that why they have kept the issue open. Okay if five years of talking won't convince you then what will? I hate to have my hopes up five years for something no one is going to give any notice. At least close this so we all know once and for all that okay you won't.

There's no excuse with this issue, they can place countermeasures for any problem this change can generate. I explained my suggestion time ago on this post: https://github.com/microsoft/vscode/issues/3429#issuecomment-695989626

[chavlji]

C'mon MS... People are begging you 5 years for this basic feature ffs!

What are the exact problems here? Selection and other bg highlights can just override theme bg color. What could possibly go wrong?!

[pouyakary]

@NetVicious yeah good point. I guess we have waited and talked for a such a long time, even we are loosing track of all the comments. This is one of the saddest things in the GitHub. At the start I thought as a joke to myself that this is getting so long, we'll wait a decade, and I mean... we actually have waited half that :) Just imagine that :)

[pouyakary]

@Tyriar @aeschli — Please just once and for all, end it. Close the issue or at least say something :(

[aeschli]

We keep the issue open as it is a valid feature request on the backlog. We still have not ruled out to implementing it at some point.

[Ganglians]

Is it possible to implement this ourselves?

[MattDMo]

I have a fairly popular color scheme for Sublime that I wanted to port to VSCode because of popular demand, but now I can't without completely redoing all the colors (it has over 400 scopes, about 25% of which have a "background" rule), because "we don't feel like supporting this basic, basic feature."

Nice job, everyone. Goodbye.

[Quest79]

We keep the issue open as it is a valid feature request on the backlog. We still have not ruled out to implementing it at some point.

A valid feature? The ability to change fonts can also be called a valid feature. Every basic and highly used feature should be in VS CODE. This is ridiculous. Who is actively in charge of green lighting this? What are their valid reasons for not?

[NetVicious]

@MattDMo There it's a lot of people waiting to the fix of this issue to change to VSCode. It's a must for all they, and we don't want to lose that syntax highlighting.

[mika76]

@aeschli out of interest, what would make Microsoft implement this feature quicker, prioritise it faster? More votes? More social media visibility?

[shot-codes]

@mika76 business value? I don't imagine implementing this feature provides much in the way of overall value for vscode. While it is basic, there is likely only small handful of people that really care about it, and most of those probably aren't choosing other text editors solely for that reason. This leaves little reason to implement such a feature; Presumably the backlog is saturated with more valuable features and they come in at such a rate that it hasn't ever been viable for them to focus on this versus something else. Sadly this isn't solved with simply implementing it ourselves as the same holds true for the revision of PRs....

[richardtallent]

Is it possible to implement this ourselves?

I can say that with the right CSS overrides, it almost works. The problem is whitespace. Since Monaco positions words rather than using normal whitespace flow, there's no current mechanism to have a background color for whitespace.

In my use case, we still use CSS to make it happen, since we can live without the whitespace also having a background color. But that could be part of the issue for implementation as a proper option, if I had to take a guess.