[hnlmorg]

A note to any developers writing console applications, please please please don't use RGB values in your terminal colour -- only use the 8 base colours plus highlight. RGB values prevent your users terminal from using the custom colour palettes your users might define (and like this site helps you to create). Aside from being a little annoying, it can cause genuine usability problems for some groups of people who use custom palettes:

- for visual impairment reasons (eg high contrast colours)

- or to differentiate different servers (eg different background colours for dev or prod servers)

- or have less contrasting colours to reduce eye strain (eg the Solarized colour schemes)

- might suffer from colour blindness so pick colours that contrast better with their condition

- or even just those that prefer a white or other non-black backgrounds for readability reasons (eg they might be dyslexic and find a non-black background or different shades of text easier to read).

I do fall into two of those categories and run into this issue a lot since there is a trend these days for developers to hard code colour values into their applications.

Equally, some developers use the "you can select a custom colour map - I just define a pretty default" argument and while that's slightly better, the best option would be still to default to the standard 8 colours (or the default unformatted text) and let users opt into RGB values if they wish. This will save your users from constantly having to define the same colour palettes in every application.

[JdeBP]

As I noted at https://news.ycombinator.com/item?id=22002036 . (-:

It has been really 16 colours since the days of AIXTerm, even though that did not get formally standardized. Only a couple of places nowadays make the error of conflating bold and bright. It's not really "8 base colours plus highlight" at all, and that's certainly not the case with the tool at hand.

You are also approaching being a decade late with a plea not to use direct RGB colour. https://gist.github.com/XVilka/8346728 started in 2014, for example.

What the tool at hand really tells us is that there are already at least 18 different ways of specifying a colour palette. Perhaps the better idea nowadays is to promote a common 16-colour-to-RGB palette mechanism for TUI applications, akin to mailcap or something.

[hnlmorg]

Direct RGB does still have its place, for example rendering ASCII or block art. Just not for stuff that's intended to be read.

[a1369209993]

We have a common 16-color-to-RGB mechanism: write \e[34m or similar and let the terminal do its damn job.

[JdeBP]

No, you do not have that. For starters, it's still a matter of debate whether the world is wholly ECMA-48:1976 yet. There are people who contend that we cannot assume universal adherence to a 1976 standard.

* https://unix.stackexchange.com/q/548158/5132

* https://unix.stackexchange.com/a/5802/5132

Then there's the matter that only colours 0 to 7 are in fact standardized in ECMA-48. That's 8 colours, not 16. The AIXTerm mechanism has never been standardized, and what has been standardized in the likes of ITU T.416 is both not the AIXTerm mechanism and badly implemented to the extent that people are still today pushing for two long-standing mistakes to be corrected by software authors.

Moreover, not every terminal agrees on how to interpret even the non-T.416 SGR control sequences. Famous and still widely used terminal emulators, such as the Linux built-in one for its KVTs, respond to boldface (SGR 1) by changing colour; in contrast to many terminal emulators where boldface means boldface and isn't a colour change. The control sequences are not the same and cannot be hardwired.

* https://unix.stackexchange.com/a/608930/5132

Personally, I am of the opinion that one can nowadays assume ECMA-48:1976 at minimum as long as one allows for "dumb" as well. But that doesn't mean further assuming the AIXTerm 16-colour mechanism. Until you go and change the Linux KVT's (and others') handling of boldface, and then the "linux-16color" entries in termcap and terminfo, to actually match your claim, your claim will remain incorrect.

(Also note the caveats at https://news.ycombinator.com/item?id=23752827 .)

Then there's the fact that a decent common TUI palette system wouldn't be 16-colour-to-RGB, because that would still need a second map. It would be better than that. That's just a barebones concept. It would be display-element-to-RGB, learning from the design of GUI palettes back in the 1980s, where the colour schemes specified colours for abstract UI elements such as "window title", "pressed button", "file", "directory", "text label", and the like. And indeed from the design of Borland TurboVision, which did the same.

[lokedhs]

In addition to what you are saying, I'd also ask developers to not use escape sequences directly but instead use terminfo. It allows you to send the correct terminal sequences regardless of the type of terminal you use.

In particular, it allows your users to completely disable the highlights by using TERM=dumb.

Also, please check if the output is a tty (the isatty libc call) I don't know how many applications with fancy coloured output that looks completely broken when redirecting to a file.

[DarkWiiPlayer]

Default to standard terminal colours and allow customization if necessary (I think vim handles colours very nicely :D)

[hnlmorg]

> Default to standard terminal colours

That's my point :)

[a1369209993]

> only use the 8 base colours plus highlight.

Those are actually called "RGBI"[0] colors (which would make the 8 base colours "RGB", though I haven't seen that usage), although that's clearly not what you mean by "RGB values".

0: 1 bit each for red,green,blue,intensity: #(r·AA+i·55,g·AA+i·55,b·AA+i·55)

[hnlmorg]

No, the colours I'm talking about aren't defined as RGBI values.

Wikipedia has good introduction to the different SGR colour parameters: https://en.wikipedia.org/wiki/ANSI_escape_code#Colors

I'm talking about 3/4-bit (8/16 colours) not 8-bit (256 colours) nor 24-bit ("true colour"). The 3/4-bit colour palette is configurable in most terminals. True colour is not.

[a1369209993]

I'm talking about the 4-bit (RGBI) ANSI color palette, used by \e[34;44;94;104m escapes. 8-bit or 24-bit color should not be supported by terminals in the first place (and certainly shouldn't be used by terminal applications), for the reasons you mentioned above.

[da39a3ee]

I think both of you are talking about the same thing.

Please don't assume that your views are generally held or will meet with general approval. I think what you're saying is completely wrong and wildly inappropriate. In general, there will exist many terminal applications where the designers should feel absolutely free to use 256 and full-RGB colors if they wish to, seeing as the technology has supported it for years.

An example is color themes for syntax highlighting; the designers of color themes obviously _can_ restrict themselves to 16-color palettes (e.g. https://github.com/chriskempson/base16) but they are perfectly free not to. I do not understand what makes you think you have the right to demand that people impose such a vast restriction on terminal applications. The web supports 256 colors and full RGB; why shouldn't terminal applications?

[hnlmorg]

> The web supports 256 colors and full RGB; why shouldn't terminal applications?

And the web suffers from all sorts of accessibility problems because developers don't take that into account. Native applications (and I'm not talking about Electron) is a better example -- Microsoft and Apple have taken accessibility concerns into account and created interface toolkits that aren't a rainbow of colours by default and which users can easily customise one colour scheme in the systems control settings to affect all native applications.

Using 256 or true colours in console applications break the terminals ability to apply the user-defined colour palette and that can bring accessibility issues with it (as well as being a little annoying for anyone who happens to prefer non-black backgrounds).

[da39a3ee]

> And the web suffers from all sorts of accessibility problems because developers don't take that into account.

So what do you suggest, that the web should use a limited palette that is user-configurable and not hard-code any colors?

I really want to say the following politely and respectfully, so please try to see it in that light: there is an upper limit to the restrictions that it makes sense to impose in the name of accessibility. There have been some awful acts of vandalism done by accessibility zealots. I'm thinking in particular of the deletion of thousands of hours of university lectures by UC Berkeley.

[da39a3ee]

> please please please don't use RGB values in your terminal colour

Can you clarify what your suggestion is please? I assume you're talking about ANSI color escape sequences. There are 3 different ways colors are represented using ANSI color escape sequences (see https://en.wikipedia.org/wiki/ANSI_escape_code#Colors)

1. Using the 16-color palette which is dynamic and under user control.

2. Using the 256-color palette, which are hardcoded colors.

3. Specifying 24-bit colors (RGB), which also hard-coded colors.

Are you asking developers of terminal applications to use neither (2) nor (3)? If so, that seems like an extraordinary, and inappropriate, request. I do hope however that developers of terminal applications make it possible to configure the application to use (1).

For example, do you disapprove of the existence of all syntax highlighting color themes unless they use only the base 16 colors?

[0xffff2]

Not OP, and not constrained by any accessibility needs, but restricting your terminal applications to (1) sounds entirely reasonable to me. At the very least, (2) and (3) should be entirely opt-in, never defaults.

[da39a3ee]

What about syntax-highlighting color themes? Although a subset of color themes (e.g. base16) are specifically designed to use the dynamic 16-color palette, my understanding is that it's routine in the color-theme world to allow yourself to hardcode colors from the 256-color palette. So an application making use of syntax-highlighting color themes would certainly make 256 color support default, wouldn't it?

[hnlmorg]

This is a weirdly specific edge case and it really depends on what type of application is using the syntax highlighting.

For example if it's designed to be a generic `cat` or `man` type utility then I'd suggest sticking with 16 colours. However if it's intending to be a fully featured TUI IDE then something like that would expect the user to configure the application before using it in any significant way and thus using 256 or true colours is more reasonable.

As it happens, I have actually implemented syntax highlighting into one of my open source projects and I stuck with the 16-colour palette. There's only so many unique colours you'd want to use before the screen becomes a mess anyway.

[da39a3ee]

OK, I think the problem was that your original post was much too strongly worded. It sounded like you thought that there was no role at all for 256-color and RGB ASCII escape color sequences. But that's clearly not true: just look at a terminal application like bat (a syntax-highlighting cat replacement), which is very popular, and uses sublime color themes most of which use hardcoded colors. In fact, nowadays, when I use the terminal applications that I use most frequently, I make use of their 256-color and full RGB capabilities. But, nevertheless, all the applications I have in mind allow the user to escape hardcoded colors and use the 16 color palette to be used.

But, they do not default to 16-color palette: for example, bat's default theme is Monokai Extended (https://github.com/jonschlinkert/sublime-monokai-extended).

So, as politely as possible, I do suggest that you should get off your high horse; yes people recognize the importance of supporting the 16-color palette but no, it's not some sort of obviously evil abomination to support and even default to hardcoded 256-colors and RGB colors. Quite to the contrary, there are several use cases among modern, popular, terminal applications. They involve color-rich scenarios such as syntax highlighting.

Don't get me wrong though, we're largely in agreement. I wouldn't want a normal terminal app to hard-code, say, a yellow color, which is only visible to users of dark terminal backgrounds, but hopeless on a white background.

[hnlmorg]

> OK, I think the problem was that your original post was much too strongly worded. It sounded like you thought that there was no role at all for 256-color and RGB ASCII escape color sequences. But that's clearly not true: just look at a terminal application like bat (a syntax-highlighting cat replacement),

`bat` is one of the examples of when 256 and true colour shouldn't be used. I have a huge amount of respect for that application, it's a well polished utility, but I found I couldn't always use it with my accessibility themes turned on and configuring it to work on different terminals and on different machines got tiresome enough that it no longer became a productive tool. Again, I otherwise have a huge amount of respect for the utility.

As I said in my previous post, I have actually written a terminal application that applied syntax highlighting and I didn't need more than 5 unique colours so it still looked good in the standard 16 colour palette. It even optionally supported underlining misspelt words. The whole thing is easy to read, easy to reason and respects the output preferences defined in a given user's $TERM.

Developers don't need 265/true colour palettes. It doesn't add anything to the application (unless the point of the application is rendering graphics in text mode) yet it does cause issues for a great many users. So I don't think it's an unreasonable point to raise.

> So, as politely as possible, I do suggest that you should get off your high horse;

Asking for accessibility in productivity tools is not mounting "a high horse". It's just asking for a little courtesy for lesser abled users. But even accessibility aside, it's daft for developers to assume that everyone is running their $TERM with a black background. There's plenty of terminal emulators that default to white backgrounds and plenty of people who have others colours in between (as discussed elsewhere in this submission, some people use colours as a sanity check so they know which terminal session is which).

> Don't get me wrong though, we're largely in agreement. I wouldn't want a normal terminal app to hard-code, say, a yellow color, which is only visible to users of dark terminal backgrounds, but hopeless on a white background.

But that's exactly the scenario you're advocating by suggesting developers should use colours that cannot be remapped in the terminal. And it's exactly the scenario I run into time and time again (hence my post).

[0xffff2]

I don't user a terminal-based editor very often, but my vim syntax highlighting uses the basic 16 colors and it works just fine for me. Personally I think a lot of syntax highlighting is noise anyway. But again, I don't really have a problem with more colors being an option. There are few things that I love more than tweaking and customizing my editor. I just want the out of the box configuration to be dead simple. Any number of options is fine, but your application damn well better display correctly regardless of my color settings, which is so much more likely if you stick to using the 16 colors I get to manage myself.

[kergonath]

Or specific uses (someone else thread mentioned image rendering; I really like the sixel terminal in gnuplot to eyeball stuff from a server without bothering with X; there are plenty other uses for high-resolution full rgb graphics in a terminal).

[JdeBP]

Actually, there are at least six. And the "E" in "ECMA" does not stand for "ANSI", nor does the "I" in "ITU". (-:

* https://github.com/jdebp/nosh/blob/79b1c0aab9834a09a59e15d47...

* http://jdebp.uk./Softwares/nosh/guide/commands/TerminalCapab...