3 ms·
If tooling would simply use the Base16 Framework[0] instead of arbitrary colors from “256 color” or “RGB” color modes, this would be much less of a problem: the
by eddyg 2y ago
If tooling would simply use the Base16 Framework[0] instead of arbitrary colors from “256 color” or “RGB” color modes, this would be much less of a problem: the output would always be displayed with (presumably) readable colors defined by your terminal.
[0] https://github.com/chriskempson/base16 https://github.com/chriskempson/base16
[1] https://tinted-theming.github.io/base16-gallery/ https://tinted-theming.github.io/base16-gallery/
- brabel 2y agoAs a CLI tool author, I don't understand how I can use base16 to "theme" my tool's output. Can you point to some resources?
- drdo 2y agoI'm not sure that I fully understood the theming aspect but one point I think is that the standard 8/8 ANSI colors are presumably picked to be readable by the terminal theme itself, independent from your application. So if you just use those in your application you don't know the actual colors that the user will see on their screen but you know that they will be something readable.
- skydhash 2y agoIt’s the first 16 colors of the 256 set. Most current graphical terminals support the latter, but they only expose the first 16 in their configuration. So using them makes your software completely customizable. I believe the tty console only use the first 8.
- z2h-a6n 2y agoI'm not sure if eddyg had a different idea, but I think the following sums it up: - base16 is a specification of how different UI elements map to colors [1], and also some tooling, configuration files, etc. to automate setting this up for many different applications. - For a user to be able to use base16 with a tool, either: - Allow the user to set their preferred colors for UI elements at a semantic level, preferrably in a config file, and even more preferrably in a separate file that can be included into the main config file so that it's easier to automate (i.e. I have a separate `colors.sh` that is loaded in my `.zshrc`). - Let the user set their shell colors however they want (presumably using [2]), and use the ANSI shell colors (and a few more) according to the base16 style guide [1]. Some translation between shell colors and base16 colors will be necessary, e.g. base16 says that a language keyword should use the color base0E, which in [2] corresponds to ANSI shell color 13. My impression is that the base16 specification is not sufficiently general for most tools to implement it in a totally unbambiguous way, but if users can set their own colorschemes with a config file, it's not hard for a user to come up with a base16-approximating colorscheme template file, from which other users can generate a config file that sets a specific base16 colorscheme. [1]: https://github.com/chriskempson/base16/blob/main/styling.md https://github.com/chriskempson/base16/blob/main/styling.md [2]: https://github.com/chriskempson/base16-shell https://github.com/chriskempson/base16-shell
- MatthiasPortzel 2y ago> the output would always be displayed with (presumably) readable colors There are several obstacles that make this not the case in practice, unfortunately. Black on white and white on black (whatever hex colors those actually are) will look fine. But different applications will use the accent colors differently. For example, some might use black text on a colored background, and others may use colored text on a black background. Some tools even use “bright” colored text on a different colored background. This is masked in most cases by iTerm2’s “Minimum contrast” setting, but when I tried to design a color palette with good contrast with that setting off, I found it to be very difficult.