[themes][semantic] default themes: new constant color

[aeschli]

Dark+ / Light +
Use the default color for constant variables.

• as done in the VS 2019: See Theme Changes to better align with Visual Studio Light and Dark themes #92965
• take advantage of constants info from semantic highlighting

[mjbvz]

Hey @aeschli just saw this in today's insiders.

For JS/TS, I feel that the new color for constants changes the character of the dark theme. It makes it feel brighter (when I first saw it, I actually thought our colorization was broken). One specific nit I have is that constants now use the same color as punctuation which makes code less legible:

Trying to match VS is a good sounding goal but I find the impact of this little change to be quite drastic (more drastic than enabling semantic highlighting in the first place). And honestly, we have a whole lot of users who are using the default VS Code theme and don't care what Visual Studio is doing

Maybe there's a compromise that won't be quite as jarring when users upgrade but still lets us convey if something is a constant or not?

[JonWallsten]

I thought it was a bug and was about to report it. It feels like the color that should be there just disappeared.

[aeschli]

I fully understand. It also took me a while to like it. Theme changes are always very controversial.
Still, I wanted to put it out to see the general reaction. I'm fine to revert it for stable if there are many negative reactions.

• I first tried to find another color, but it's hard and equally controversial. Also there has been many requests for more colors in the default themes and we always resisted with the argument to keep it simple and clean
• we define a new Default theme that we only give as default to new users. If we do that, it should be more than just a single color change, but a a new, fresh design.

@misolori Your thoughts?

[JonWallsten]

@aeschli: Would it be possible to use something in between cyan and white? Or go darker?
The reason I got the feeling something was wrong with the theme was because everything else in the Dark+ theme is different colors. So it felt like something was "missing" when the color disappeared and turned white. Personally I don't care if let/const have the same color, but since they are still very similar from a semantic POV maybe a more subtle color change would suffice?

[IllusionMH]

The change of color for consts in a test run in Insiders. Please give it a chance and please add a thumbs up/down on that issue.
From #95434 (comment)

It's a bit strange to close opened issue as duplicate of this and expect feedback on closed issue. Could you have an open one for feedback?

I don't have any preference for color, however default "white" doesn't have any as with plain text and would be nice to have something else.

---

take advantage of constants info from semantic highlighting

I don't think that knowledge that some variable/property is constant is more useful to discard type of data in variable as was implemented for JS/TS.
In JS some teams (our too) use const for everything except that we need reassignments let (counts are const 10k+ vs let ~1.5k) so almost every variable in our app is white.
It's also (almost ?) impossible to create readonly object properties in plain JS - no changes here.

Previous behavior with value type should have greater priority than generic constant.
Because what is use cases to know that something is constant? VS Code will warn immediately if I attempt to assign new value. It won't be highlighted consistently while viewing local and PR diffs so doesn't help here.

[aeschli]

Reopened for feedback

[mattacosta]

I'm not finding this particularly useful, especially on properties. You have to know something about the kind of immutability being used in order to determine if/when a property can be written to.

Unfortunately, some extensions/grammars do not respect the subtle distinctions. For example, in TypeScript, while the readonly modifier is correct semantically, it's not the same as a const modifier, and yet that is the scope being used on read-only properties. If you switch to a language with properly scoped read-only fields, then you now have two colors for the same thing.

This is also made worse if a language server is inconsistent in its semantic highlighting. Again, from TypeScript:

class A {

  public readonly roField = 1;

  // Without a setter, this should be read-only too, especially since it
  // could also implement an abstract readonly field from an interface.
  public get roProperty(): number { return 1; }

  public foo(): number {
    return this.roField /* white */ + this.roProperty /* light blue */;
  }

}

Another problem is that enum members aren't easily distinguishable in code anymore. This is mainly because the light green color was replaced and isn't being used on them or the enum identifier. It would be a lot better if the enum identifier got that color by default now, which would also be consistent with VS2019 as well.

That said, I would like to see the default theme be a little closer to VS2019. Another alternative could be to reduce the change to just local constants (if possible, pending other issues) and enum members (which are never ambiguous because all members are always const).

[MirkSerain]

I also thought this was a bug when I saw it. I agree with @IllusionMH, my JS team also uses const for everything and now I have a lot of white text in my dark theme. It just feels like part of the highlighting isn't working or that the variable i'm using doesn't exist.

[aeschli]

We will give an new color a try that is closer to the variable color. Please try it out a while and let me know whether the new color is better or if we should go back to the original theme.

[tamuratak]

Version: 1.45.0-insider
Commit: a250df7
Date: 2020-04-24T20:46:59.782Z
Electron: 7.2.2
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Darwin x64 17.7.0

I am a user of Default Light+. The current color of constant variables, variable.other.constant,variable.other.enummember { "foreground": "#328267" }, is too light when the background color is white.

It is difficult to distinguish it from the color of comments.

1.44.2:

Insiders:

[Edit]

The color, #328267, does not meet WCAG 2 AAA Compliant when the background color is white. Although I do not say themes always must meet it, I want to say that default themes must meet it.

https://www.sbwfc.co.kr/ColorChecker/

[mattacosta]

There's not a lot of contrast with existing colors in the dark theme either. It's kind of in no man's land between this, type names, and unused variables/parameters.

[aeschli]

@misolori see above, comment on the contrast of the new color.

[miguelsolorio]

@tamuratak thanks for the feedback, our accessibility color contrast goals are to meet WCAG AA so you will find this throughout all of our themes. The new const color meets WCAG AA at 4.6:1, see below.

cc @isidorn

[aeschli]

To verify:
Open the Dark+/Light+ themes on a TypeScript file and look at the coloring of const variables, enum members and read-only properties . They should have a different color than regular variables.
Verify that the color is not to be confused from the keyword and commend color.

[LeeviHalme]

Can you please remove it? Or at least make it toggleable. I thought this was a bug because it was so ugly lol

[mkedevel]

Default Dark Theme:

• x - variable is not used
• y - variable is used
• a - variable is used
• b - variable is not used

This color creates more problems than benefits

[chybisov]

I loved my yellow enums! Bring them back! 😢

[gnaeus]

Declaration and usage of the same variable have different colors. Looks a bit strange:

[aeschli]

@gnaeus Not with semantic highlighting enabled...

[mkedevel]

@aeschli, why console.log changes color, when this option is enabled?

[gnaeus]

@aeschli no I didn't disable semantic highlighting. My combination of flags:

    "editor.semanticHighlighting.enabled": true,
    "editor.semanticTokenColorCustomizations": {
        "enabled": false,
    },

[gnaeus]

Also here is the settings for all who loves the old behavior:

"editor.semanticTokenColorCustomizations": {
  "rules": {
    // different color for all constants
    "*.readonly": "#9cdcfe",
  }
}

OLD	NEW

[chybisov]

@gnaeus enums should be yellow :)

[sashahavia]

Can someone return back the original color for constants or give a decent workaround?
It's clashing with the green color. Not sure why this was done. The last two updates are messing with default color scheme a lot and not very beneficial for the users. I understand that you checked the new const color and that it meets WCAG AA at 4.6:1 but in reality it confuses users and is not readable

I tried using this

 "editor.semanticHighlighting.enabled": true,  // it only works if this set to true
    "editor.semanticTokenColorCustomizations": {
        "rules": {
          // different color for all constants
          "*.readonly": "#9cdcfe",
        }
      }

to return to old behavior but it only works if I set "editor.semanticHighlighting.enabled": true which actually makes things worse since the last update where we needed to set it to "editor.semanticHighlighting.enabled": false to undo highlighting changes

Also the workaround makes everything blue which now clashes with functional component names and so on

[aeschli]

To get the old colors back you need to add the following to the settings:

    "editor.tokenColorCustomizations": {
        "[Default Dark+]": {
            "textMateRules": [
                {
                    "scope": ["variable.other.constant", "variable.other.enummember"],
                    "settings": {
                        "foreground": "#9CDCFE"
                    }
                }
            ]
        },
        "[Default Light+]": {
            "textMateRules": [
                {
                    "scope": ["variable.other.constant", "variable.other.enummember"],
                    "settings": {
                        "foreground": "#001080"
                    }
                }
            ]
        },
    },

[sashahavia]

To get the old colors back you need to add the following to the settings:

    "editor.tokenColorCustomizations": {
        "[Default Dark+]": {
            "textMateRules": [
                {
                    "scope": ["variable.other.constant", "variable.other.enummember"],
                    "settings": {
                        "foreground": "#9CDCFE"
                    }
                }
            ]
        },
        "[Default Light+]": {
            "textMateRules": [
                {
                    "scope": ["variable.other.constant", "variable.other.enummember"],
                    "settings": {
                        "foreground": "#001080"
                    }
                }
            ]
        },
    },

Thank you for a quick response. It worked

[arielkuzminski]

Just spend 30 minutes trying to fix this bug by reopening VSC then reinstalling it because I was sure that my coloring was broken.
Now I read that, this is a "feature".

[LeeviHalme]

To get the old colors back you need to add the following to the settings:

    "editor.tokenColorCustomizations": {
        "[Default Dark+]": {
            "textMateRules": [
                {
                    "scope": ["variable.other.constant", "variable.other.enummember"],
                    "settings": {
                        "foreground": "#9CDCFE"
                    }
                }
            ]
        },
        "[Default Light+]": {
            "textMateRules": [
                {
                    "scope": ["variable.other.constant", "variable.other.enummember"],
                    "settings": {
                        "foreground": "#001080"
                    }
                }
            ]
        },
    },

Thank you! It is unbelievable that WE as users have to make our own fixes around this new "feature". Though you guys at Microsoft would listen to us... 😒

[evg656e]

Holy moly, I have color blindness, and after recent update, I thought it some kind of bug. You should change color schemes with care. Reverting to old style

[arielkuzminski]

Holy moly, I have color blindness, and after recent update, I thought it some kind of bug. You should change color schemes with care. Reverting to old style

Exactly. I'm color blind too, so that's why I have major problem with this. I guess this feature hasn't been consulted with UX and hasn't been tested.
Second major bad feature for me in VSC in 2020. I wonder if it's beggining of downfall of VSC and some new "light, fresh" player should appear on market.

[barbunzel]

Leaving a comment here just for feedback. I feel a little too picky about this, but I spent more than an hour trying to figure out what was wrong with the const coloring. I thought it was a bug or some intrusive extension messing up my settings. Thanks for the "solution"!

[vnestere]

Spent couple hours today reinstalling vscode, was sure its a bug. Had to go with color customization fix mentioned above to revert it back to normal colors.

Why would you add such "features" that break normal workflow for so many people? I'm wondering how many hours collectively developers who use vscode have wasted trying to work it around back to normal.

[mattacosta]

See #97373 for the discussion about improving the color.

[giuliano-december]

To get the old colors back you need to add the following to the settings:

    "editor.tokenColorCustomizations": {
        "[Default Dark+]": {
            "textMateRules": [
                {
                    "scope": ["variable.other.constant", "variable.other.enummember"],
                    "settings": {
                        "foreground": "#9CDCFE"
                    }
                }
            ]
        },
        "[Default Light+]": {
            "textMateRules": [
                {
                    "scope": ["variable.other.constant", "variable.other.enummember"],
                    "settings": {
                        "foreground": "#001080"
                    }
                }
            ]
        },
    },

Thank you! It is unbelievable that WE as users have to make our own fixes around this new "feature". Though you guys at Microsoft would listen to us... 😒

This is awesome. I love you man. I was going nuts with the new coloring

[triforcely]

Well, I'm not color blind but I still find the new colors much harder to read than the old ones. The "WCAG" argument is a joke, are you really putting the algorithm above real users feedback?

[oskarkook]

The issues with this:

1. It provides very little value. I don't really care whether a variable is a const or not. In the cases where I do, I will get feedback that it's a const very quickly anyway.
2. It's hard to parse and is confusing. By making every little thing have a different color, it ends up being very hard to remember that color X stands for Y thing. As a result, it just confuses you because you're looking at rainbow-colored text. Different colors should stand for very significant differences where it makes it easier to read text than harder. (See how I used italics for specific words to enhance my point? If the whole text was a mixture of bold and italics, it would be very hard to read.)
3. The color does not fit into the theme. The contrast against the dark background is not good enough in my opinion, even though you claim that it satisfies some standard. The usual (mutable) variable color works really well against the dark background, I prefer it highly over this color. Most of my variables are constants, so this is a serious eyesore.