Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

A big problem is that, even when you ignore 256 and true color support, and limit yourself to the 16 color palette, there’s no consensus on whether the 16 colors are backgrounds or foregrounds. Some CLI write text in foreground color over color_x, while others do it with background color.


If you’re a CLI, you should never (a) set background colours, or (b) use more than the 16 colours range¹, unless the user configures it so.

If you’re a TUI (as in, full-screen terminal app), you should probably not (a) set background colours, or (b) use more than the 16 colours range¹, unless the user configures it so.

—⁂—

¹ And you can’t even wisely use most of the 16 colour range—the intense colours might be higher or lower contrast, so they’re not useful how people want to use them, and black and white could both be either the higher contrast or literally invisible, when used against the default background; and blue, yellow, bright yellow, bright cyan are each very difficult to see on some common themes, those that’s becoming less common.


Sadly, the state of CLI and TUI tools is that background colors _will_ be encountered soon or later, if you use a wide range of software. And I struggle quite a bit sometimes to make everything in my terminal legible.


I'm genuinely unsure what you mean here. In SGR, 30-37 are foreground colors, 40-47 are background, and the brights are 90-97 for foreground and 100-107 for background. Even the second bright set is quite old, xterm calls them the aixcolor because they originated in IBM's AIX in the 1980s. I've never seen terminal software which doesn't support these and definitely never encountered one where the difference between foreground and background was negotiable. The concept of a color independent of being foreground and background can't be expressed in SGR codes.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: