Documentation update: explain the color names and how they related to ECMA-48 #3715

@j4james commented on GitHub (Sep 2, 2019):

I assume the names are mostly based on the ANSI ECMA-48 standard (you can see the colors listed on Wikipedia) except they're using purple instead of magenta. And while the standard only defined 8 colors, the increased intensity attribute was often used to produce brighter versions of each of them, hence the BrightXXX variants.

And even if you think the .NET names are better, they couldn't really change them now without causing every existing config to break (under the existing scheme, Blue defines the dark shade of blue, but with .NET names, it would be defining the bright shade).

@j4james commented on GitHub (Sep 2, 2019): I assume the names are mostly based on the ANSI ECMA-48 standard (you can see the colors listed on [Wikipedia](https://en.wikipedia.org/wiki/ANSI_escape_code#Colors)) except they're using _purple_ instead of _magenta_. And while the standard only defined 8 colors, the _increased intensity_ attribute was often used to produce brighter versions of each of them, hence the _BrightXXX_ variants. And even if you think the .NET names are better, they couldn't really change them now without causing every existing config to break (under the existing scheme, _Blue_ defines the dark shade of blue, but with .NET names, it would be defining the bright shade).

claunia commented

@DHowett-MSFT commented on GitHub (Sep 3, 2019):

I miss the days when we simply had an indexed array of the first 16 ECMA-48 colors. ☹️

@DHowett-MSFT commented on GitHub (Sep 3, 2019): I miss the days when we simply had an indexed array of the first 16 ECMA-48 colors. ☹️

claunia commented

@WSLUser commented on GitHub (Sep 4, 2019):

I think we should re-use in addition to any extra colors we have.

without causing every existing config to break

That is the only problem. We'll need a script to modify the existing config after Terminal is updated. New installs won't require it.

@WSLUser commented on GitHub (Sep 4, 2019): I think we should re-use in addition to any extra colors we have. > without causing every existing config to break That is the only problem. We'll need a script to modify the existing config after Terminal is updated. New installs won't require it.

claunia commented

@ExE-Boss commented on GitHub (Sep 5, 2019):

I think we should do this while Windows Terminal is still in the preview 0.x version, which allows (and expects) breaking changes according to semantic versioning.

@ExE-Boss commented on GitHub (Sep 5, 2019): I think we should do this while **Windows Terminal** is still in the preview 0.x version, which allows (and expects) breaking changes according to [semantic versioning](https://semver.org/#spec-item-4).

claunia commented

@zadjii-msft commented on GitHub (Sep 5, 2019):

Honestly, I kinda like the Red/BrightRed pairings more than the DarkRed/Red pairings. @j4james is correct that we were trying to follow the ANSI standard. Either one we pick is going to result in some subset of the population unhappy with our choice here.

We definitely shouldn't be using "purple" as a color name, that was definitely an oversight. That should be magenta.

@zadjii-msft commented on GitHub (Sep 5, 2019): Honestly, I kinda like the Red/BrightRed pairings more than the DarkRed/Red pairings. @j4james is correct that we were trying to follow the ANSI standard. Either one we pick is going to result in some subset of the population unhappy with our choice here. We _definitely_ shouldn't be using "purple" as a color name, that was definitely an oversight. That should be magenta.

claunia commented

@WSLUser commented on GitHub (Sep 5, 2019):

Can't we have both? We can still stick to ANSI standard while providing the Dark options in addition.

@WSLUser commented on GitHub (Sep 5, 2019): Can't we have both? We can still stick to ANSI standard while providing the Dark options in addition.

claunia commented

@kojoru commented on GitHub (Sep 5, 2019):

The original reason for this issue was my genuine confusion over what BrightWhite and BrightBlack actually means when I first opened the config.

Those terms are pretty much ungoogleable until you know what you're looking for. I doubt that terminology is known outside of the circle of people who are actually working on implementing console-related stuff.

Not having any confusing names in it is the main reason I think ConsoleColor enum is objectively better, beyond simply bikeshedding.

But if you decide otherwise, at least the issue calls for more documentation. I imagine something like a table explaining different ways of naming colors for consoles that's easily available for someone editing the colors.

@kojoru commented on GitHub (Sep 5, 2019): The original reason for this issue was my genuine confusion over what `BrightWhite` and `BrightBlack` actually means when I first opened the config. Those terms are pretty much ungoogleable until you know what you're looking for. I doubt that terminology is known outside of the circle of people who are actually working on implementing console-related stuff. Not having any confusing names in it is the main reason I think [ConsoleColor enum](https://docs.microsoft.com/en-us/dotnet/api/system.consolecolor?view=netframework-4.8) is objectively better, beyond simply bikeshedding. But if you decide otherwise, at least the issue calls for more documentation. I imagine something like a table explaining different ways of naming colors for consoles that's easily available for someone editing the colors.

claunia commented

@DHowett-MSFT commented on GitHub (Sep 5, 2019):

We're probably not going to make changes to the names of the colors we support (withholding possible updates for purple->magenta), but we're happy to document why the brights are they way they are. Sorry for the confusion!

@DHowett-MSFT commented on GitHub (Sep 5, 2019): We're probably not going to make changes to the _names_ of the colors we support (withholding possible updates for purple->magenta), but we're happy to document why the brights are they way they are. Sorry for the confusion!

claunia commented

@craigbarnes commented on GitHub (Dec 6, 2019):

I miss the days when we simply had an indexed array of the first 16 ECMA-48 colors

But ECMA-48 only specifies 8 colors...

@craigbarnes commented on GitHub (Dec 6, 2019): > I miss the days when we simply had an indexed array of the first 16 ECMA-48 colors But ECMA-48 only specifies 8 colors...

claunia commented

@DHowett-MSFT commented on GitHub (Dec 6, 2019):

Yes, you have me on a technicality.

@DHowett-MSFT commented on GitHub (Dec 6, 2019): Yes, you have me on a technicality.

claunia commented

@DHANUSHRAJA22 commented on GitHub (Aug 25, 2025):

Hi, I'd like to work on this documentation update! Please let me know if you have any extra context or tips.

@DHANUSHRAJA22 commented on GitHub (Aug 25, 2025): Hi, I'd like to work on this documentation update! Please let me know if you have any extra context or tips.

claunia commented

@DHowett commented on GitHub (Aug 25, 2025):

Nope, this issue and the history of the console subsystem is all we have to go on.

@DHowett commented on GitHub (Aug 25, 2025): Nope, this issue and the history of the console subsystem is all we have to go on.

claunia commented

@AvishekDas5 commented on GitHub (Sep 24, 2025):

Hi! I'd like to work on this documentation. I plan to research ECMA-48 standards and create clear documentation explaining the color naming rationale.

@AvishekDas5 commented on GitHub (Sep 24, 2025): Hi! I'd like to work on this documentation. I plan to research ECMA-48 standards and create clear documentation explaining the color naming rationale.

claunia commented

@lhecker commented on GitHub (Sep 24, 2025):

To be honest, at this point I'd personally rather just close this issue.

@lhecker commented on GitHub (Sep 24, 2025): To be honest, at this point I'd personally rather just close this issue.

claunia commented