91–100 of 212 posts
Really interested in this for cargo/rustc. We run into issues where we need one or two more colors but all that is left after going for the basic semantic colors is magenta (odd choice), and black and white (not safe without inspecting the theme).
Just use direct color mode (24bit, "true color")[1] and there will be no need for a palette. > Fewer terminals support truecolor. From what I know all modern terminal emulators in all operating systems support it now. [1] https://github.com/termstandard/colors
At the currently known limits of physics where Heisenberg Uncertainty Principle, Abbe's Limit, Quantum Shot Noise and such become our sensing barriers, we suspect we need only about 6000 bits per pixel to represent a digital twin of the electromagnetic field of the sensor-covered volume of space. At 60 fps, that is 1.8 Zettabits per second. Scale out data volume accordingly when using using 18.5 sexdecillion fps (Planck time fps).
What surprises me is these "limits of the fabric of reality as we know it" mind experiments fairly concretely point the way on the many roads towards Kardashev Scale implementations, and is not that different from Archimedes' "Sand Reckoner" and Hindu cosmological Kalpa time scales. History doesn't quite repeat, but rhymes yet again.
Earlier quoted context omitted.
I don't want true colours. I want what I already have, 16-255, to stay reliable in the future.
Is that really optimal? It is already true in that case that your colour schemes do not work for people with opinionated colour settings. Isn't this just relying on a quirk? The point of not using truecolor is to respect the colour preferences of the user. XKCD 1172? https://xkcd.com/1172/
What would be optimal is semantic _styles_ (not colors):
- The developer marks the string "XXX" as an error message without even trying to style it.
- The platform/user agent/terminal/whatever displays the string in the default style for "error".
- The user can adjust the theme of their platform/user agent/terminal/whatever to fit their needs/wants.
The good thing with the 256c palette is that colors in the 16-255 range are fixed, which gives us a very high level of confidence that 146 will be a muted violet and so on. This is very useful for colorscheme developers because it allows us to provide a pretty good and consistent experience across the widest range of terminal emulators. If the 256c palette is generated from a -- potentially wild -- 16c palette then t…
> and consistent experience across the widest range of terminal emulators. Instead of aiming to provide a "consistent experience", you should instead prioritize providing consistent functionality , while avoiding impeding users' control over their own particular experience.
Earlier quoted context omitted.
I know 16 colours is limiting, but one of my biggest pet peeves is CLI / TUI developers creating their own custom themes using colours outside of that because odds are, they’re going to generate a colour scheme that is harder to read for a lot of people with visual impairments, people who prefer a white or coloured background for eye comfort, people are dyslexic and find non-black backgrounds easier to read, and othe…
I agree. I always customize the blue color on my terminal because dark blue on black is completely unreadable to me (and I'm not even color blind!). For some reason, every single terminal emulator defaults to a blue that's unreadable on a black background (I think typically #00f). If a tool overrides my color settings, it too usually picks a dark blue that's unreadable on my black background.
I have to select that text to change the background to read it.
What I would like is HDR colors, just to access more saturated light colors. I don't want less saturated blue to make it lighter, just crank up the blue channel to 11. I still don't want brighter colors than #fff though.
I think your wish is self-contradicting. `#fff` is so-called _device_ colour -- a device like a LED-based display uses it directly to drive the LEDs, where `#fff` means that the red, the green and the blue channel are already "cranked to 11". The `f` here is equivalent to 11. HDR uses a different color format, I think -- exactly because `#fff` is otherwise either ambigous, or has to map to a different colour gamut --…
The good thing with the 256c palette is that colors in the 16-255 range are fixed, which gives us a very high level of confidence that 146 will be a muted violet and so on. This is very useful for colorscheme developers because it allows us to provide a pretty good and consistent experience across the widest range of terminal emulators. If the 256c palette is generated from a -- potentially wild -- 16c palette then t…
> which gives us a very high level of confidence that 146 will be a muted violet Is there anything you can do with that information though? This piece of information only becomes useful if you know what colour the background is . And you should also know the colour of text and everything else. What if the background is muted violet? What if the background is white and the foreground is muted violet? I don't want you…
The exact values of your 0-15 don't matter to me and they don't matter to you either, because you chose to use my 256c colorscheme to begin with.
Earlier quoted context omitted.
I agree. I always customize the blue color on my terminal because dark blue on black is completely unreadable to me (and I'm not even color blind!). For some reason, every single terminal emulator defaults to a blue that's unreadable on a black background (I think typically #00f). If a tool overrides my color settings, it too usually picks a dark blue that's unreadable on my black background.
Is there a human that can read that dark blue on black or is it just us who has their eyes wired differently? I have to select that text to change the background to read it.
But there is no standard or standard body anywhere for terminal colors so there is no obvious way to improve this situation.
And no urgency either, because all terminal emulators allow users to customize the palette anyway.
The article is well argued and well written, as far as I’m concerned.
What’s needed if you really want adoption is to define a term; something like 256-ex for extended. Or whatever. But folks and apps need to be able to say; we’ve implemented or we support 256-ex. Without this label is hard to drive adoption.
The heartbleed thing from a few years back best taught me this.
Good luck I hope to see broad adoption it’s a great idea.
Give it a name, better yet move the copy onto a website with the same name also and a little icon folks can add to their website if they implement this k to their terminal app.