You’re aware that turning on a blue filter at the same brightness level will obviously decrease the overall emittance of the display? Most displays are already way too bright for ideal viewing conditions at maximum brightness, let alone in a completely dark room. Of course it will blind you at that setting and of course mostly turning off a third of the sub-pixels will reduce the issue.
That’s why one should trust science over anecdotal evidence because a good scientist would control for brightness...
Many differences to my attempt:
Luminance is kept different between colours according to some subjective “individuality”, I touched on why I decided against this in another comment. This has rippling effects as instead of being able to just make chroma uniform, one now needs to subjectively adjust both in tandem to get the same apparent brightness, which will never be as precise as doing it mathematically (which would require a full colour appearance model like CIECAM16). But then, luminance and chroma are still different across colours, so this still appear somewhat uneven. Compare the colour swatches here https://codepen.io/rguiscard/full/OJvZLpd to those of Selenized and you should see the difference.
Same things goes for the choice of hues, they’re further apart on what appears to be an HSL-based colour wheel, but by no means optimally spaced (at least there’s no mention of it).
Plus for all of this they used CIELab which simply isn’t as perceptually uniform as it claims to be, especially with respect to hue, so optimal spacing wouldn’t have even been possible.
It definitely improves on some of the same issues I had with Solarized, but in a non-rigorous way, with more of a “good enough” approach.
The perceptual distance is the same between all colours according to the most recently available scientific data (with a relatively small margin of error for technical reasons).
There could be issues with your display calibration (most likely), things like f.lux/night shift and so on that cause these to deviate from the calculated ideal values.
There’s no set timeline for further implementations. I’ll try to create the most requested ones whenever I can in my free time, but I’m also open for others to contribute!
Colorbrewer is safe for CVD but not optimized to be as distinguishable as possible no matter your impairment as far as I’m aware. That’s what I’m trying to do in a different project.
Colormaps have very different constraints due to having to cover a continuous ramp and are therefore also not optimal for categorical palettes. I personally like these the best overall: https://www.fabiocrameri.ch/colourmaps/
but there are many good options at this point.
I absolutely agree that intelligent highlighting or added emphasis to at least some part of the code is very worth investigating. I would argue it should probably be used more sparingly than colouring, but could be complementary. By combining the colours from the base and the contrast++ palette this would even be possible with Penumbra while maintaining the clean separation between colour properties.
In this area, as a novice coder, I am absolutely out of my depth though, so I’d have to defer to actual experts for the implementation.
Someone else brought up a similar point on comment emphasis but I’ve seen the opposing opinion too.
Oh awesome! I didn’t have time to look that deep into it, sorry for missing that part.
Switching to OKLab actually reveals how narrow the bands of available colours can be in the different dimensions and how difficult it would probably be to hand-pick the colours that I’ve chosen. I agree now that they’re probably more complementary.
It would be awesome if the tool allowed you to set constraints like the ones I used.
The reasoning on the first two points is the same, yes, simply because I agree with Ethan’s. The two big differences are: I’m aiming for perceptually uniform colour differences instead of the same luminance and my background colours are directly sampled from daylight.
For the colours, this means uniform chroma and hues that aren’t hand-picked but optimised (on top of that using a more hue-accurate colour space).
I’d argue there’s enough of a difference, especially in the visual result, to make this more than an iteration, but even if it was simple iterative, there’s nothing bad about that and it can still be valuable work without being plagiarism .
I’m on a Mac with a Retina display so that’s probably why I haven’t noticed this issue. I don’t know of any way to account for this off hand though, even if I had noticed it.
Is it at least acceptable with the contrast++ version?
Yes, the blue light content is higher as screens use RGB instead of the full spectrum of light, but for this purpose I care about colour perception and as long as the stimulus in the cones is the same (which it should be if your display is properly calibrated, most are actually quite decent at this point straight out of the factory), this does not make a difference.
Limiting the blue part of RGB makes the available colour space so small, that the design goals of this palette will be impossible to achieve.
As far as I know, the most recent science says that blue light levels from displays are actually pretty much negligible in terms of overall health, but don’t quote me on that. For wakefulness, ideally you should probably not be working that late at night anyways and there’s f.lux and night shift for that if you must. These inherently make legibility of any colour worse though, including this palette.
I’m not sure if I’m already using the closest colour in terms of luminance or not, I’d have to check.
If not, I’m very open to pull requests on the theme, including fundamental reworks.
Otherwise there might be an argument whether one would want to make the closest de-emphasised colour less so, but that would require more fundamental changes to the palette (which I’m also open to for the background colours!). I think for this part I looked at what others were doing so I might have gotten it wrong from them.
I think most of the criticism is fair and to be expected, especially as the design goals are very “opinionated” in a sense and on the other hand, everyone will have a subjective opinion on a colour palette themselves.
The original intent was really just to use it myself, but if at least a couple other people may benefit, I feel like putting in the effort to make it shareable is worth it.
If you care about accessibility and these colours have any sort of function or meaning within the app, I’m afraid I would advise against using these colours as they were created for a quite specific use-case — colouring tokens within “fluid” text.
If you just like them aesthetically and all they’re meant to do is look good, feel free, though I have to say they weren’t designed with aesthetics in mind at all.
For accessible categorical colour schemes, check out Okabe-Ito, Paul Tol or colour brewer.
I guess there’s an argument to be made to put the “available for” section closer to the top, but the main repository I linked is meant more as a design template that needs all this explanation, the VSCode extension for example is a lot more succinct.
Plus the folders in the repo are named after what implementation they contain which I hoped was self-explanatory.
I acknowledge at the bottom that Solarised was one of the inspirations for this and some similar design principles apply in terms of the background colours, but really the motivation was a lot more specific and the construction fundamentally different. I really don’t see where you are getting “carbon copy”.
Correct, OKlab is nothing fundamentally new in terms of the underlying science as it’s based mainly on CIECAM16, but it makes working with perceptual distances of colours a lot more user friendly.
The saturation (or to be more accurate in this case, chroma) is actually already as high as possible (unless I’ve made a fundamental mistake) given the constraint that we want it to be uniform across colours and also uniform luminance. sRGB simply doesn’t allow for more sadly and I’m afraid it will probably be a long time before a new standard colour space for consumer displays comes around that would improve this.
This tool that others have linked is pretty good if you’re fine with relaxing the constraints (just make sure to change to colour space to LCH OKlab): https://huetone.ardov.me.
There are a couple of hand picked categorical palettes for visualisations and at least for VSCode (see the issues on the main repo), there are also some themes. None of them are truly optimized as far as I’m aware, just chosen to be good enough, and this is also something I’m working on (in the visualisation context).