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.

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.

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.

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.

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.

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

+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?

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.

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?

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.

Sadly this was working a while ago

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

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

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

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

@Tyriar Look at VSCodes changelogs over the last years and tell me that all of this was actually more important for the success and longevity of this project than getting tmTheming right in its entirety.

All in all, the point still stands: Your teams priorities are very frustrating to me and a lot of others.

Just started using Blazor and was wondering if I can add a background colour to my .razor directives like I can in Visual Studio. Guess bold will have to do haha.

If this is what you people want, then it is quite doable.

I see a fully black background in the image above. What's the point?

I see a fully black background in the image above. What's the point?

If I increase the brightness on my screen I can see that the script scopes are slightly brighter than the others. Not by much though haha. Perhaps would have been been a better illustration of it was a totally different color... Not even sure if that's what it's showcasing either 🤔

I see a fully black background in the image above. What's the point?

+1 I would love to be able to 'shade' the background of eg. <script>, <style> blocks in a .svelte, .vue or even .html file to show separation of different areas.

Like this?
#3429 (comment)

Perhaps would have been been a better illustration of it was a totally different color...

#3429 (comment)

Fenweldryn, babakness, 0xbs0d, nelsonlaquet, NetVicious, Kronuz, zinckiwi, pouyakary, debrouchee, Zireael, saioacoder, chavlji, katerlouis, mika76, sarensw, learn2reid, ryanolsonx, sladec

Follow:

Step 1: Stop bothering @Tyriar

Step 2: Install this:

https://marketplace.visualstudio.com/items?itemName=fabiospampinato.vscode-highlight
Highlight - Visual Studio Marketplace

Put this in your settings.json

"highlight.regexes": {
 // highlights script tag 
 "(<script\\b[^>]*>([\\s\\S\n+]*?)<\\/script>)": {
      "decorations": [
        {
          "backgroundColor": "#5a5a5a10",  // Color of your choice, this works perfect for me.
          "isWholeLine": true
        }
      ]
    },
    
 // highlights style tag 
  "(<style\\b[^>]*>([\\s\\S]*?)<\\/style>)": {
      "decorations": [
        {
          "backgroundColor": "#5a5a5a10",
          "isWholeLine": true
        }
      ]
    },

 // highlights code blocks 
  "(```[\\s\\S]*?```)": {
      "decorations": [
        {
          "backgroundColor": "#5a5a5a10",
          "isWholeLine": true
        }
      ]
    },
    
 // Create your own regex like above to suit your requirements.
 
}

Result:

Step 3: Just remember me in your prayers.

Hm. Regex parsers usually seek for trouble. They may not find it immediately.

We do need it.

I jst want to make the area of ​​​​the code block a lighter color,

so I can tell the difference between the plain text and the code at a glance.

We do need it.

I jst want to make the area of ​​​​the code block a lighter color,

so I can tell the difference between the plain text and the code at a glance.

I'm having good luck using CSS overrides directly. Just set a unique style for the token in the config, note the CSS class it creates and override it in your CSS.

Been working for years flawlessly, and I have full ability to also do some borders, rounding, specific font weights, and other styles that aren't supported in the config. (Just avoid anything that would change the width of a token, such as margins or x-padding.)

Frankly at this point I'd rather they just allow us to specify the CSS class (instead of or in addition to the autogenerated class name) than to build new styles into it, since there are way too many awesome things you can do with CSS.

I'm having good luck using CSS overrides directly. Just set a unique style for the token in the config, note the CSS class it creates and override it in your CSS.

How to do it?

I'm having good luck using CSS overrides directly. Just set a unique style for the token in the config, note the CSS class it creates and override it in your CSS.

Also very curious how exactly you did this? I'm using "Custom CSS and JS Loader" to tweak Material Theme to look more like how my SublimeText Material theme looked. Quite a lot of visual details which made the ST version way more efficient for me.

But this extension isn't the most solid and often requires me to execute the command "Reload Custom CSS and JS", after which VSC cries that the installation is now corrupt :D – Which way are u using to add the backgrounds?

Maybe you could post the exact classes you have to alter to simply add a slightly different background to <script> sections :) – I'd really appreciate it (and I think a lot more :D) – I can't wait to unsubscribe from this github issue ^^

There's no script involved here, y'all.

1. Register your custom language tokenizer.
2. Create a theme with some random foreground color or some other unique style combination for one of your tokenizer rules.
3. Confirm that your theme color/etc. is being applied.

I assume you've gotten that far if you're asking about background colors being unsupported.

Now, right-click on some highlighted word in your editor and inspect the DOM to see what class name Monaco auto-generated for that theme rule. Then, use plain old CSS somewhere on your page to override that class with whatever styling is more to your liking, including backgrounds.

You cannot predict the specific class name that Monaco will assign fully, but as long as you don't change the tokenizer or theme rules, the class names will be the same for all users. You'll just need to shift some CSS around when you have to make updates to your custom language.

I've been doing it this way for years, works fine.

Bikeshedding?: Yes
Legitimate reasons this is complicated?: Yes
Community being overbearing?: Yes
Do we still need it?: Yes

+1 for the ability to set background color.

Re: the custom CSS method. Let's say you want to make type annotations have a grayish background, like so:

Here's one way to do this.

1. First, add the following rule to your theme file.

{
	"name": "Types",
	"scope": ["meta.type.annotation"],
	"settings": {
		"fontStyle": "italic bold underline strikethrough"
	}
},

2. Then install apc extension: https://github.com/drcika/apc-extension
3. Point "apc.imports" (https://github.com/drcika/apc-extension#apcimports) to a .css file on your hard drive
4. Add the following rule in that .css file

.mtks.mtku.mtki.mtkb {
	background-color: #00000030;
	font-weight: bold;
	font-style: unset;
	text-decoration: none;
}

This method doesn't really scale for obvious reasons (you quickly run out of the permutations), but it's okay if you only have a small number of things you want to set a custom background color for.

Does anyone know the exact commit that removed this?
I've been adding a few options to my own VSCode source, maybe I can patch it back in as an option.

@richardtallent

... Then, use plain old CSS somewhere on your page ...
Sorry, can you please elaborate on this. Where do I put this CSS? (or, what extension do you use to apply CSS? I tried apc-extension mentioned in the following comment but it did nothing and was unstable).

Still relevant

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

I'm not familiar with how text / canvas layering in the editor component works, so excuse my ignorance, but I wonder if the mix-blend-mode CSS property could be of any help here? (and also what the performance cost of using it would be...) Has anyone tried experimenting with this?

Related on Stack Overflow:

• How to change background color for a token in VSCode?
• Is there any way to change background color of comments in VScode?

Hm. Regex parsers usually seek for trouble. They may not find it immediately.

#580 would presumably resolve this; if extensions could access the textmate scopes, then they could use this to apply custom highlights instead of using regexes.

I was so surprised when didn't find "background" hinted by autocomplete. But I was even more surprised when I saw this thread. I was literally astounded when I read that 8 years ago the team stated "I'd say we accept this as limitation and tell to better use themes that don't rely on background colors." and still there we are.

We are talking about a very basic and very expected feature here. Everyone using a customizable coding IDE expects a background to be changeable along with the foreground. I understand might be a difficult issue to tackle, but nothing that your very competent team couldn't handle I guess.

Probably not tomorrow, but please ping us back on this and give us hope claiming that someone is working on this and that there is a deadline, even far, in sight.

Does anyone know the exact commit that removed this?

Looks like it was removed at or before 122a07b in December 2016. See how the color service only puts foreground color for the token, at standaloneColorServiceImpl.ts:31.

I've been adding a few options to my own VSCode source, maybe I can patch it back in as an option.

I think it's way too far back for that. See /pull/212294 for a simple alternative.

### wow.
really?
this
is
still
a
thing?