solasluaith

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...

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!

Already on my rapidly growing to do list!

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.

Feel free to make either an issue or even a pull request, I’m very much looking for feedback on the implementation!

Do you have the same issues with the Dark Contrast++ version?

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.