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!

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.

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.

> displays are actually pretty much negligible in terms of overall health, but don’t quote me on that.

Yeah, forget that. It's unreasonable to assume "negligible" is in any way or form acceptable when it comes to vision. It fucking isn't.

Here's something fun! You can actually subjectively measure how bad it is. All it takes is or white background, in full screen, full brightness, in a dark room. It creates a burning-like sensation in the eyes. Then stop, wait a few minutes until it fades and repeat the process with the filter on.

You'll actually notice a difference.

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

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.

Thanks, that's very kind of you.

I'm using an open source calendar component to visualize my agenda. I have various types of events I'm showing (scheduled work items, events and completed items). I'm having a difficult time deciding on a color scheme.

Upcoming events should be emphasized. Completed work items are useful information ("I finished this") but they should be least noticeable.

I'll play around with both your color scheme and the references you provided just to see if something sticks.

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.