[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)

[aeschli]

We had it in, but turned it off as it conflicted badly with the other background decorations we have (selection, word highlighting). I'd say we accept this as limitation and tell to better use themes that don't rely on background colors.

[Tyriar]

It's such a handy feature of tmThemes though to draw attention to important things. it's used frequently across themes for invalid and deprecated scopes.

[onecrayon]

I'd say we accept this as limitation and tell to better use themes that don't rely on background colors.

I strongly disagree with this. Rather than disabling a core component of tmThemes, you would be better off encouraging people to properly port their favorite tmThemes to support VSC's custom background keys when the backgrounds conflict.

Consider the difference in message:

Current: "if you rely on a theme that uses different background colors for different scopes, you must switch themes completely because we have disabled this functionality."

Port on conflict: "if you rely on a theme that uses background colors, you may need to make a minor update to the theme in order for it to look great in VSC (or you could switch to a different theme if that's too much effort)."

The first gives the user no options, and does nothing to encourage support for VSC's unique theme settings beyond themes specifically authored for VSC.

The second allows the user to make use of whatever theme they like (with caveats), and encourages theme developers to add support for VSC's custom theme keys to existing themes because it broadens the number of editors the theme will support without impacting the theme's display in other editors.

It's bizarre to me that you want to take pains to support tmThemes out of the box (to the point of breaking your to-my-mind more sensical scope targeting logic in 1.9), but then silently disable a core colorization component because it sometimes conflicts with your proprietary additions.

[pbaksa]

You should add some documentation about which keys you support in a .tmTheme. https://code.visualstudio.com/docs/getstarted/theme-color-reference Would be a good place.

[bugs181]

Does this apply to blocked comments too? I'm having a difficult time trying to figure out how to change the background color of a multi-line comment.

Example:

    <dict>
        <key>name</key>
        <string>Block comment</string>
        <key>scope</key>
        <string>source comment.block</string>
        <key>settings</key>
        <dict>
            <key>background</key>
            <string>#9b9b9b</string>
            <key>foreground</key>
            <string>#FFFFFF</string>
        </dict>
    </dict>

The background color code is not getting applied here. Only the foreground (text) color.

[babakness]

I'd like to be able to style the background so + 1 from me.

[0xbs0d]

+1 for me as well. I wanted to port my favorite emacs theme to Code and now I don't see the point. Will this be re-implemented?

[babakness]

Maybe the conflict can be resolved by adding an alpha value to the color so that the colors can bleed through each other. This is a very desirable and goes a long way to improving readability. One such use case is embedded languages with their own syntax highlighting. Without a background color, it can become difficult quickly distinguish that the embedded language as a different block of logic without making the entire block monochromatic.

[Fenweldryn]

I think this is what I've been searching for since I moved from sublime. On sublime I had a theme that, on the same php file, had different color backgrounds for PHP, HTML and JS code. Is this the situation here?

[onecrayon]

On sublime I had a theme that, on the same php file, had different color backgrounds for PHP, HTML and JS code. Is this the situation here?

The situation here is that it is impossible for themes to have different background colors for different scopes. So you cannot duplicate your Sublime theme in VSCode.

[0xbs0d]

Sadly this was working a while ago

[Tyriar]

@immigrantsheep I don't believe the editor ever had support for background colors.

[0xbs0d]

@Tyriar it did and I remember briefly using it. You have @aeschli comment above from Mar 4, 2016 as well confirming it.

[Tyriar]

My mistake, I was fresh on the team at that point 😄

[bilogic]

Since it was turned off, is it possible for it to be turned back on by users who need it?

[aeschli]

To get the background colors to work correctly requires additional work. We currently have no resources to look at that.

[lankymart]

Would really like this wasn't until I'd built my textMateRules using editor.tokenColorCustomizations that I spotted the background wasn't being set but the foreground was, which inevitably sent me here looking for a fix.

[Raydir]

+1 for me used several hours to find out why my theme wasn't showing background Color on Scope Settings. (and several more to realize it was not my fault -.-)

[nadise]

+1 I have a large MD document in which i'm having trouble spotting the fenced codes from the normal text

[webdevnerdstuff]

This is the only reason I haven't switched to using VSCode. I use a custom build theme and have for many years. I have spent years perfecting my custom theme to my liking, so changing it is not welcomed, especially when almost all other code editors allow it. Also rebuilding my custom theme is not something I want to do either, as it would still change many things that do use a background color.

Not having the ability to style the theme how users want it restricts people from doing what they want to do and is forcing them to change. Why make people change what they have been doing for years, because it conflicts with something VSCode built and didn't think about?

We had it in, but turned it off as it conflicted badly with the other background decorations we have (selection, word highlighting). I'd say we accept this as limitation and tell to better use themes that don't rely on background colors.

This is really not a good explanation and a poor excuse. Perhaps you should consider that people do use background colors. If it conflicts with background decorations, than that's on the user to either change those colors, or let them decide if they want to live with it or not, not for the editor to say "do what I want you to do, no exceptions." This is almost as typical as Microsoft IE giving excuses over the years for always being very far behind other browsers. Ignoring the people who use it, while just doing whatever they want, and in turn losing a large amount of the market.

Telling people to use a different theme is like telling a client "just use different colors", and is not the kind of answer you want to here as a user. That's like saying "Sorry we don't care, just change how you do things because we do not want to take the time to support how people have been doing things for years".

Just my two cents.

[nelsonlaquet]

I would also REALLY love to see this put back in; it's very helpful for templating language (PHP, Razor, etc) to distinguish which part is the templating language and which part is the raw output. I haven't used VS for a while, but IIRC, Visual Studio does the same for Razor directives - so why not Visual Studio Code?

I understand there being conflicts with other highlighting features, but wouldn't that be a matter of simply adding in new scopes, allowing them to be controlled by the theme itself? What's wrong with allowing user themes to style the background of wherever VS Code currently highlights text?

[pouyakary]

There can be a theme that offers a bad use of background colors but one can make an extension to replace all the source codes with nonesense on formatting, show unrelated funny cat ascii art on hover and replace intellisense suggestions with the list of US box office movies.

Any feature of the vscode API can be used in a bad way therefore if you go on with that logic you must disable the whole API and extensibility of the vscode.

It’s the users job to reason if they want the intellisense to show them box office movies and it’s also the users job to see if they want a theme that offers wrong coloring.

Meanwhile, there are a ton of very nice themes like Neon Glow and Tutti Fruity where the background colors are all the beautiful parts and without background coloes they don’t look even 10% as good.

[NetVicious]

This thing it's the only customization I need to use VS Code as my programming editor

If the problem, as @aeschli says, it's related to the colors of selection, word highlighting, ... the solution it's very easy, add these options (selection, word hightlighting, ...) to the themes and the theme creators will have the option to change all, adjusting they to the color scheme they used on the theme.

VS Code it's nearly fully customizable so why do not add more power...

[babakness]

@NetVicious Yes, this! Maybe a middle ground could be that if the author of said library has not designated the required colors or perhaps turn on a flag explicitly mentioning that they have, a quiet error is logged and the background color behaves as it currently does.

[NetVicious]

A third option could be a flag in the VS Code settings page to enable background change for tmThemes files with a big warning about this can create problems. Another solution could be a floating button after a theme change allowing the user to undo the theme change, like Windows does when you're changing the screen resolution. If the user sees the theme it's not working good with the colors he can undo the theme change.

PD: Someone knows which was the last version of VS Code which allowed to change background color.

[Kronuz]

This is where I use the background in my theme:

{
    "tokenColors": [
        {
            "name": "Embedded",
            "scope": "markup.fenced_code.block.markdown",
            "settings": {
                "background": "#00000022"
            }
        }
    ]
}

And this is what it looks like (VS Code vs Sublime Text):

I'd love to be able to get that darker background in VS code. Can that be achieved in some other way other than background?

[aeschli]

I hear you, but it's another complexity on top of what we have. My estimate is that it's 1-2 milestone work to get it fully right. So vote for it so this makes it to a plan.

[pouyakary]

I just noticed that backgrounds on backgrounds is already implemented on the diff view and it works just as expected and very good:

[bilogic]

@aeschli, how do we vote for this? any link etc? Thank you.

[aeschli]

@bilogic To vote, add a 👍 on issue description

[pouyakary]

Given the fact that this conversation has been going on for such a long time and almost everyone gave really good facts on how right it is, how possible it is, how much it is need and so and and so forth... Isn't it better to come to a conclusion? It feels as it's taking too long... (thinking for 2 years on token backgrounds is a little bit too much)

[NetVicious]

Hi @aeschli ! Any progress on this issue? On a June message you said this issue will be fixed in 1-2 milestones. We got July and August milestones and I don't see nothing related to this on the changelogs. You're working on it for the next milestone for September? Regards,

[aeschli]

@NetVicious In my comment I just estimated the work, no commitment to work on the issue. As 1-2 month is a considerable investment, this needs to be justified by the number of votes.

[bilogic]

@aeschli How many votes are needed to justify this investment?

[aeschli]

Depends all on the number of votes for other requests. When creating the roadmap for the coming months (see https://github.com/Microsoft/vscode/wiki/Roadmap) we look at the top voted issues and try to find solutions for them. Some features have over 2000 votes...

[lankymart]

I've just tweeted out to my followers, hopefully, it will raise awareness...

Recommend others do the same.

[BenTreeser]

+1 for me this is also the only reason not to switch from sublime text. I would love to have this feature be impelemented.

[Zooce]

+1

[zinckiwi]

Would love to see this. I'm stuck on Atom because I can't live without https://atom.io/themes/flatwhite-syntax.

[kanlukasz]

I hope that the background color will be supported, because it is very useful. For example, if you're working with Wordpress themes - unfortunately Wordpress mixes HTML and PHP, so a different background for PHP in WP templates helps a lot

[pouyakary]

3 years and still going... :(

[debrouchee]

+1 Love my sublime theme with different background colors for PHP, JS and HTML. Would like to switch to vscode if this feature is supported!

[NetVicious]

@wangweixuan can you confirm with the commit you send some days ago will fix this bug and will allow us to have themes with background-color ? With only that change this bug will be fixed?

I know @aeschli said the background color selection on the themes can create problems if the developer of the theme uses the same colors VSCode uses for selection or word highlighting. But let developers to solve that problem instead of limiting us.

[safizn]

Just passing by, tackled this issue trying to add background color for all type tokens in .js files. I'm using Latest TypeScript and Javascript Grammar to support more expressive rules for types syntax highlighting in js files. The feature for background color in .tmtheme files still doesn't work. VSCode insiders version 1.33

[chrisbg69]

That's why i'm using WebStorm, there background of mixing code HTML/Js working perfectly. If VsCode make this update, i change to them...

[pouyakary]

Espresso is a really good looking editor. It has very good looking icons and vibrant sidebar are big factors, but the most screen real-estate belongs to the theme which uses significant amounts of background colors to make it cute and pretty.

[jcklpe]

+1

[misaelvergara]

This would make life so much easier. Upvote! +1

[Quest79]

Depends all on the number of votes for other requests. When creating the roadmap for the coming months (see https://github.com/Microsoft/vscode/wiki/Roadmap) we look at the top voted issues and try to find solutions for them. Some features have over 2000 votes...

How many "votes" did adding font changing need? Or obscure stuff like changing the color of the cursor?? This is basic functionality. Most people wont "vote" for this sort of thing becuse they assume something so obvious is already included. What a silly argument not to add it. Reminds me of the Chrome team refusing to add bookmark dividers. I think something went wrong and im in the bizarre-o timeline.

[mkanet]

I just switched from Sublime Text 3 to VSCode. I am able to fix sluggishness in VSCode by getting fast PCs. However, I can't fix missing token background colors.