Great to see that getting more traction than my submission. I hope to find time to incorporate it into my terminal. Are there already some projects generating the various color schemes?
Removing contrast towards more washed out colors does not look like an improvement. Examples at the end look less legible both in too much light and in less light.
I can't see your point towards the washed out colors. Did you really compare the two Examples? I did compare both color schemes (the dark blue ones), and they seem very close together with a bit (nearly unnoticeable) more contrast for the OKSolar Color Scheme. Here is it side by side (the bottom one is oksolar):
I definitely can relate. In the light version, the background has now less color, it looks more washed out.
However, the author did improve the contrast when looking at the numbers. I ran the default text color through a contrast check and see this results (I hope I took the correct colors):
So this is likely better, but not as accessible as selenized. When looking at the writeup there was maybe a bit too much focus on equal color contrast vs raising the contrast in general? Regardless, this is a nice evolution, and the equal contrast approach combined with selenized higher contrast approach could make for the perfect combination.
After having used Solarized Light for about a decade, I have now tried out Selenized Light for nearly two weeks and I am liking it a lot. It is a gradual improvement, but very much an improvement nonetheless.
In particular, respecting the ANSI colour codes makes pretty much every programme work great out of the box. I respect that Solarized tried to pack the entire colour scheme into the ANSI colour codes, but the occasional breakages are less than ideal.
Yeah the main problem with Solarized is not the coordinate system, it's the bizarre mapping of ANSI terminal colors. The way Selenized does bold/bright/reverse text makes far more sense to me. Perhaps Selenized could also be adjusted according to the same process described in the article.
> For me, the contrast between text and the background is just a little too low (especially if I’m working in a bright space), and you can see that it also varies between different token types.
Strange. For the dark scheme, it fixes the saturation and lightness difference between colors, but it doesn't seem to improve the contrast ... at all? Are my eyes lying to me? You decide: https://i.imgur.com/vFa06CE.png
I think this is an interesting approach, maybe I'll try using it with a significantly darker background color.
To me the problem with solarized dark has always been that my brain keeps telling me that my monitor is broken as it "bleeds backlight". I like the rest of it but whenever I use it I just turn the background to more or almost completely black. So much better.
I guess the same very low contrast is a problem for the light one too. This here did not improve it.
I wish there was a theme generator that just took few colors and palletes on input then generated config for a bunch of apps
I took some dark theme (twilight anti-bright from emacs) and just tweaked some values to my liking (making background darker was one), then moved with same theme (manually...) to IntelliJ IDEA and few other apps
It's funny how the last section with the screenshots mentions "preserving accessibility". "Fixing the lightness and only modifying hue and chroma" is not a recipe for good accessibility and the screenshots demonstrate it.
I'm severely green-blind and in the earlier screenshots of the Solarized palette I already hat issues telling red and orange, and blue and violet apart. But with the new palette I now struggle with red, orange AND green, and magenta and cyan also have become less distinct from each other.
Solarized wasn't very accessible to begin with (few syntax highlighting color palettes are) but this is just worse. If you learn about color theory as a hobby, please also take the time to learn about color vision and before making claims about accessibility also learn about how color vision deficiencies affect perception.
It's nice that the author admits they had to learn about color theory in order to approach this, i.e. they didn't know much about color before, but please don't claim this is an "improvement" if you really only tried to increase the light-dark contrast of the text against the background. Solarized is a fairly low-contrast theme to begin with and increasing its contrast while maintaining its general aesthetic would have been an interest goal but this article doesn't seem to actually be interested in doing that.
Preface: I am autistic, and live in a non-autistic world. Yes, I want to be taken into account, but not by default. It can really hurt if you cannot be taken into account though.
I believe a color scheme or font should not, by default, take into account color blindness or dyslexia. I mean, we could do that, but the reward would be too low compared to the cost because the amount of people with such disability is too low compared to healthy amount. Instead, users should have the option to opt for a colorblind or dyslexia color scheme or font, just like there's lifts in public space but also stairs, and its assumed most users can use the stairs (else you'd get congestion). The only exception is things like traffic signs. But given HN is an American website, I believe the US is putting emphasis on written text on traffic signs where symbols (picture language) would suffice, and improve on the matter (not just because not all speak English but more because of reading taking more effort than observing a sign, leading to errors).
I too am autistic. I don't see how that's relevant or an appropriate comparison though.
Most specifically "colorblind-friendly" color schemes suck. Most "regular" color schemes are at least partially accessible to colorblindness though. My complaint is that the author claimed the changes "preserve accessibility" while objectively making the theme less accessible. If the colors are indistinguishable in greyscale, that is not a good thing. Heck, there's not even one true way to determine what the "greyscale equivalent" of a given color is.
The author's initial complaint was that Solarized doesn't have enough light-dark contrast between the text and the background and took a stab at solving this after reading a little bit about color theory.
Don't get me wrong, this is an interesting hack (which makes this relevant for HN) but my concern is with the author making misleading accessibility claims and calling it an "optimized" or "improved" theme (to the point that others have commented they are downloading and using it themselves) while clearly demonstrating a lack of understanding of accessibility and admitting to having a very limited knowledge of "color theory".
Specifically, there was no need to homogenize the colors like this in order to increase the light-dark contrast of the theme. Even from a design aspect alone it made the theme blander, less interesting. The author lacks the knowledge to understand what makes the theme work, so how can they claim they have improved upon it?
Again, it's an interesting hack and a fun creative exercise and the result may even serve the author's and others' needs. But neither did it "preserve accessibility", nor did it "improve" nor "optimize" the theme. Your argument seems to be that restricting color palettes to make them more accessible by default limits creative choices, but my point is that arbitrarily pinning the lightness as an amateur attempt at improving light-dark contrast has this exact same effect (i.e. making the result less interesting) while additionally making the result less accessible.
For someone with dichromacy, I would recommend using a color scheme specifically designed for your particular variant of color blindness. It would be pretty easy to re-orient the hues of the accent colors around the two primaries you can perceive, but optimizing for deuteranopia and protanopia would make it worse for people with tritanopia, so I didn't try to solve that problem. I'm sorry it didn't work for you, and hope your strategy of complaining about stuff people made for free pays off in the future, although I have my doubts.
And for what it's worth, I ran this color scheme through filters simulating deuteranopia, protanopia, and tritanopia, and actually coded in them for at least a couple of hours each to see what it was like, and I personally preferred a consistent minimum foreground/background contrast over distinguishability between the accent hues.
> For me, the contrast between text and the background is just a little too low
I have always thought this with Solarized, on many monitors over many years. Perhaps my eyes aren't as good as others, but i found it instantly fatiguing
One thing I'm bit confused about is the relationship between oklab(/oklch) and different colorspaces; are srgb-oklab and p3-oklab different things? Or is oklab something that exists independent of srgb/p3/whatever? In web they seem bit intermixed in a confusing way. And does HDR add yet another dimension here is needed for "full" color specification.
The best example I know of is the OkLCH color picker from Evil Martians (https://oklch.evilmartians.io), linked at the end of the article. It shows the gamuts of sRGB, p3 and rec2020. You need a screen capable of showing them to appreciate the difference (recent Apple devices are all p3 capable).
I don't mean for this to sound negative but I'm confused by the effort to make the different shades the same perceived brightness.
Isn't a significant part of a colour scheme the ability to more easily distinguish between elements? In my terminal and text editor I want to pick out the relevant information quickly.
I hate asking stuff like this because it sounds like I'm dismissive of the really cool article/experiment I just read.
I guess the goal is for all text elements to be readable against the background, which requires a certain minimum perceptual contrast regardless of hue. I don't know if there's also some constraint on the maximum contrast as well. Perhaps readability is compromised when contrast varies to much from word to word?
Author links to a json file https://meat.io/oksolar.json but haven't done manual jetbrains theming so hoping more experienced eyes have taken a stab at it.
32 comments
[ 3.9 ms ] story [ 65.5 ms ] threadhttps://i.imgur.com/wcu2r7O.png
However, the author did improve the contrast when looking at the numbers. I ran the default text color through a contrast check and see this results (I hope I took the correct colors):
solarized: https://webaim.org/resources/contrastchecker/?fcolor=657B83&... (4.12:1)
OkSolar: https://webaim.org/resources/contrastchecker/?fcolor=657377&... (4.6:1)
selenized: https://webaim.org/resources/contrastchecker/?fcolor=53676D&... (5.36:1)
So this is likely better, but not as accessible as selenized. When looking at the writeup there was maybe a bit too much focus on equal color contrast vs raising the contrast in general? Regardless, this is a nice evolution, and the equal contrast approach combined with selenized higher contrast approach could make for the perfect combination.
[0]: https://github.com/jan-warchol/selenized/
https://github.com/jan-warchol/sensible-dotfiles
In particular, respecting the ANSI colour codes makes pretty much every programme work great out of the box. I respect that Solarized tried to pack the entire colour scheme into the ANSI colour codes, but the occasional breakages are less than ideal.
Strange. For the dark scheme, it fixes the saturation and lightness difference between colors, but it doesn't seem to improve the contrast ... at all? Are my eyes lying to me? You decide: https://i.imgur.com/vFa06CE.png
I think this is an interesting approach, maybe I'll try using it with a significantly darker background color.
I guess the same very low contrast is a problem for the light one too. This here did not improve it.
Nowadays I mostly use something else.
I took some dark theme (twilight anti-bright from emacs) and just tweaked some values to my liking (making background darker was one), then moved with same theme (manually...) to IntelliJ IDEA and few other apps
I'm severely green-blind and in the earlier screenshots of the Solarized palette I already hat issues telling red and orange, and blue and violet apart. But with the new palette I now struggle with red, orange AND green, and magenta and cyan also have become less distinct from each other.
Solarized wasn't very accessible to begin with (few syntax highlighting color palettes are) but this is just worse. If you learn about color theory as a hobby, please also take the time to learn about color vision and before making claims about accessibility also learn about how color vision deficiencies affect perception.
It's nice that the author admits they had to learn about color theory in order to approach this, i.e. they didn't know much about color before, but please don't claim this is an "improvement" if you really only tried to increase the light-dark contrast of the text against the background. Solarized is a fairly low-contrast theme to begin with and increasing its contrast while maintaining its general aesthetic would have been an interest goal but this article doesn't seem to actually be interested in doing that.
I believe a color scheme or font should not, by default, take into account color blindness or dyslexia. I mean, we could do that, but the reward would be too low compared to the cost because the amount of people with such disability is too low compared to healthy amount. Instead, users should have the option to opt for a colorblind or dyslexia color scheme or font, just like there's lifts in public space but also stairs, and its assumed most users can use the stairs (else you'd get congestion). The only exception is things like traffic signs. But given HN is an American website, I believe the US is putting emphasis on written text on traffic signs where symbols (picture language) would suffice, and improve on the matter (not just because not all speak English but more because of reading taking more effort than observing a sign, leading to errors).
Most specifically "colorblind-friendly" color schemes suck. Most "regular" color schemes are at least partially accessible to colorblindness though. My complaint is that the author claimed the changes "preserve accessibility" while objectively making the theme less accessible. If the colors are indistinguishable in greyscale, that is not a good thing. Heck, there's not even one true way to determine what the "greyscale equivalent" of a given color is.
The author's initial complaint was that Solarized doesn't have enough light-dark contrast between the text and the background and took a stab at solving this after reading a little bit about color theory.
Don't get me wrong, this is an interesting hack (which makes this relevant for HN) but my concern is with the author making misleading accessibility claims and calling it an "optimized" or "improved" theme (to the point that others have commented they are downloading and using it themselves) while clearly demonstrating a lack of understanding of accessibility and admitting to having a very limited knowledge of "color theory".
Specifically, there was no need to homogenize the colors like this in order to increase the light-dark contrast of the theme. Even from a design aspect alone it made the theme blander, less interesting. The author lacks the knowledge to understand what makes the theme work, so how can they claim they have improved upon it?
Again, it's an interesting hack and a fun creative exercise and the result may even serve the author's and others' needs. But neither did it "preserve accessibility", nor did it "improve" nor "optimize" the theme. Your argument seems to be that restricting color palettes to make them more accessible by default limits creative choices, but my point is that arbitrarily pinning the lightness as an amateur attempt at improving light-dark contrast has this exact same effect (i.e. making the result less interesting) while additionally making the result less accessible.
And for what it's worth, I ran this color scheme through filters simulating deuteranopia, protanopia, and tritanopia, and actually coded in them for at least a couple of hours each to see what it was like, and I personally preferred a consistent minimum foreground/background contrast over distinguishability between the accent hues.
I have always thought this with Solarized, on many monitors over many years. Perhaps my eyes aren't as good as others, but i found it instantly fatiguing
Generally, OKLab is its own independent color space. It's not like HSV for example, which is just a transformation of sRGB.
Isn't a significant part of a colour scheme the ability to more easily distinguish between elements? In my terminal and text editor I want to pick out the relevant information quickly.
I hate asking stuff like this because it sounds like I'm dismissive of the really cool article/experiment I just read.
Author links to a json file https://meat.io/oksolar.json but haven't done manual jetbrains theming so hoping more experienced eyes have taken a stab at it.