18.04.2026 – Pavel Klavík, Kamila Klavíková

We have recently added Dark Mode into OrgPad, and it was much bigger task we originally anticipated. In this blog post, we discuss our experience and the problems we had to solve along the way. We discuss color spaces and design decisions behind OrgPad's new Dark Mode palette. We show how we manage color themes in ClojureScript and use color palettes in CSS. And we deal with inverting colors in MathJax math formulas, both in CSS and 2D canvas.

#development, #webdev, #OrgPad, #CSS, #tech, #dark mode, #2D canvas

We've released Dark Mode for OrgPad a few months back, and it was a gargantuan change. The work ended up being far bigger than we had expected. OrgPad’s dark palette now includes around 100 new colors, and the result looks really beautiful, much better than we originally imagined. The pull request ended up containing 155 commits across 285 files, with roughly 2.7k lines of code added. Since then, we’ve already made a few more fixes and improvements on top of it. And because OrgPad is fully written in Clojure and ClojureScript, those lines of code do a lot of heavy lifting.

In this article, we share how we solved key problems. We hope that it helps you with your own projects. One good example is math formulas on the web. A common approach is to use MathJax, which converts LaTeX sources into SVG images. Those formulas are often rendered in black, which makes them hard or impossible to read in dark mode.

This problem appears on many websites. For example, the accepted answer in one Stack Overflow discussion says that because the formulas are images, nothing can be done. This is simply wrong. A straightforward solution using the CSS filter property has been available since 2016:

Color spaces

When designing dark mode, choosing the right color space becomes critical. Different color spaces describe colors in different ways, and some make it much easier to reason about relationships between colors. For a broader overview, see Axel Thevenot’s excellent article on color spaces.

We review here three color spaces: RGB, HSL and okLCH. We created most of OrgPad's dark mode palette in HSL, and later moved to okLCH.

RGB color space

The best-known color space is RGB, where each color is described by three coordinates: R for red, G for green and B for blue. These values are usually integers between 0 and 255, or floats between 0 and 1. For example, OrgPad's blue title color is . RGB colors can also be written in hexadecimal format as #RRGGBB, so the same blue is #2F7BA7. The RGB model matches how screens produce color by combining red, green, and blue light. If you zoom in on a display, you can see these subpixels directly.

RGB is simple and closely tied to hardware. Unfortunately, it’s not intuitive for people. Consider the following three colors from OrgPad's palette:

• #2F7BA7, the blue title color
• #B6E5FF
• #7654AD

How are they related? Looking at these values, it’s hard to tell. You cannot easily see that the second color is the matching blue background color, and the third color is a purple title color.

HSL color space

For this reason, many color spaces are organized around more understandable parameters. One of them is HSL, introduced in 1978 in the classic paper Color spaces for computer graphics. It consists of hue, saturation, and lightness:

• Hue is an integer between 0 and 359. It describes the position on the color spectrum in a circular way. It goes red → orange → yellow → green → blue → purple → pink → red, exactly as in OrgPad's color palette.
• Saturation is a float between 0 and 1, describing how colorful the color is. For 0, we get a gray color, while 1 gives the full color.
• Lightness is a float between 0 and 1. At 0, the color is fully black; at 1, it is fully white. At ½, the color appears at full intensity, such as pure red (#FF0000).

Geometrically, HSL color space is a cylinder where hue describes the angle, saturation the distance from the center and lightness the height from the bottom. The bottom face is fully black and the top one is fully white.

Let's take a look at the same OrgPad's colors again:

• blue title color: ,
• blue background color: ,
• purple title color: .

Now the relationships become obvious. Both blue colors share nearly the same hue, while the purple shifts along the spectrum. The background blue is also much lighter and more saturated.

Converting between HSL and RGB

You can specify HSL colors directly in CSS and elsewhere in the browser. For example, OrgPad's blue title color can be written as hsl(202 0.561 0.42).

Converting between RGB and HSL is also straightforward. Here is a Clojure implementation for converting HSL to RGB:

The reverse conversion from RGB back to HSL is simple as well:

okLCH color space

By contrast, okLCH is relatively new. It was introduced in 2020, became part of web standards soon after in 2021, and is now widely supported across modern browsers. It consists of three parameters: lightness, chroma and hue. They work similarly to HSL, but the order of parameters is reversed.

• Lightness L is perceived brightness of the color, as a float between 0 and 1.
• Chroma C describes the amount of color. It is usually a float between 0 and 0.4, but is theoretically unbounded.
• Hue H describes the position on the color spectrum as an angle in degrees between 0 and 360. Again, hue goes red → orange → yellow → green → blue → purple → pink → red, exactly as in OrgPad's color palette.

okLCH is based on research into human vision and perception. For example, it is well known that, due to evolutionary history, we can perceive many more shades of green than of other colors. And when saturation or lightness changes linearly, the perceived effect is not linear. You can experiment with these parameters yourself at https://oklch.com. The entire color space, visualized in 3D, is more complex:

Consider the color spectrum as defined in HSL and okLCH. The color spectrum in HSL is much more uneven, with visible vertical bands around certain colors. This unevenness makes it harder to create consistent palettes. In okLCH, the spectrum changes evenly.

When we started working on the dark mode palette, we did not know okLCH existed, so we used HSL instead. We only discovered okLCH near the end, when most of the palette was already done. We are now storing our palette in okLCH, which will make future modifications easier. If you want to dive deeper, this article about okLCH in CSS is a great resource.

Converting between okLCH and RGB

okLCH colors can be used directly in CSS and elsewhere in the browser. For example, OrgPad's blue title color is described as oklch(0.8975 0.0603 232.51).

Converting between RGB and okLCH is more involved because it involves multiple steps and many constants. Further, okLCH color space is larger, so it can describe colors which cannot be represented in RGB. That means we have to cap the RGB coordinates at the end. Conversion works in the following steps:

RGB ↔ linear sRGB ↔ okLab ↔ okLCH.

This converts between RGB and linear sRGB:

Converting linear sRGB into okLab consists of three steps. The first step is linear, multiplying the coordinates by a 3×3 matrix. Then comes the non-linear step of taking the cube root of the output. Finally, another linear step multiplies the values by a second 3×3 matrix.

Since these matrices are invertible, to convert in the opposite way, we just need to do inverting steps in the opposite order:

Last, we need to convert between okLab and okLCH. This is simply just a transformation of in Cartesian coordinates into in polar coordinates. We already have helper functions for this in OrgPad.

To convert between RGB and okLCH, we just need to do all these steps at once. We can do this elegantly using Clojure threading macro:

OrgPad's color palette

All colors in OrgPad are defined in okLCH. They are stored in a single Clojure map colors, which is used throughout the codebase.

Each light mode color has a matching dark mode variant stored under the same name with the dm- prefix.

For cells and links, we need several related colors: title color, background color, fill color, and others. These are defined separately for each of 15 base colors, such as :color/blue or :color/purple. They are then merged into colors map with the appropriate suffixes.

So what is oklch->hex? For faster rendering, smaller code and simpler computations in animations, we store colors as RGB hex strings rather than as okLCH coordinates.

We have already seen oklch->hex*, the function that converts an okLCH color to a RGB hex string.  oklch->hex is a simple Clojure macro wrapping oklch->hex*. If the input consists of numerical constants, it runs oklch->hex* at compile time and the call is replaced with the resulting hex string. Otherwise, oklch->hex* runs in runtime.

So we actually store this in OrgPad's binary. The function oklch->hex* is not even included in OrgPad's client production code, optimized by advanced compilation and tree shaking.

Design philosophy behind dark mode

Dark mode in OrgPad is not just an inverted light theme. It’s an intentional redesign. The goal was simple in theory, but demanding in practice: keep content readable during long sessions, both during the day and at night, while making the interface feel genuinely beautiful.

Warm background instead of cold gray

Most dark modes rely on blue-gray or near-black backgrounds. We didn’t.

At night, people usually work under warm artificial light, not daylight reflected from the sky. A cold blue-gray background clashes with that environment and feels harsh. That is why OrgPad’s dark mode has a subtle yellow tint. It fits better with warm lamplight and feels calmer to the eye.

This was not just a design hunch. We tested colder variants and kept seeing the same result: blue-gray dark modes felt off. The warmer base simply worked better.

By contrast, OrgPad's light mode uses cooler bluish tints for background and grayish cells. In that sense, the two themes complement each other: dark text on light background versus light text on dark background, cold light versus warm light.

Foreground elements are lighter on purpose

In OrgPad, foreground elements are lighter than the background. This reflects how light works in the physical world. Objects closer to us catch more light, while distant surfaces stay darker.

That subtle difference helps create a natural sense of depth without heavy borders or strong outlines. Even on a busy canvas, your eyes can quickly tell where to focus.

A lighter dark mode overall

OrgPad’s dark mode is lighter than what you might be used to. That choice is intentional.

Extremely dark backgrounds tend to create a “black hole” effect. Colors lose their character, and many elements start to collapse into similar dark shades. Human vision is simply less sensitive to differences in dark tones, so the usable color range becomes narrower.

A lighter background preserves more distinction between colors and makes them feel more natural. Pictures, charts, and embedded content stay readable without extreme contrast or awkward adjustments. Dark mode should support thinking, not fight with your material.

Accessibility of colors

Accessibility is often treated as an afterthought. Getting everything perfect is expensive and not always realistic for a small team. Still, many improvements are simple and benefit everyone.

For dark mode in OrgPad, readability was the priority. Text, buttons, icons, and links must clearly stand out from the background. Low contrast causes problems for many people—those with weaker eyesight, color vision deficiencies, or just tired eyes late in the day.

Colors look different to everyone, so you can't rely on gut feeling. That is why accessibility standards matter. They help you make decisions based on measurable rules, not personal taste.

WCAG 2

The most widely used accessibility standard today is WCAG 2 (Web Content Accessibility Guidelines). It defines minimum contrast ratios between text and background. If you meet the ratio, the content is considered readable. These rules are part of broader web standards and are widely adopted.

But WCAG 2 has limits. It reduces contrast to a single number, while human vision is more complex. Some combinations fail the test but still look fine. Others pass but feel hard to read.

A typical example is blue backgrounds. White text on blue often fails WCAG 2, while black text passes—even though many people find the white version easier to read.

APCA

Because of these issues, better approaches are emerging. One of them is APCA (Advanced Perceptual Contrast Algorithm).

Instead of a simple number, APCA models how people actually perceive contrast. It considers text size, weight, and background brightness, making it more accurate.

APCA is not an official standard yet, but it's a step in the right direction. Accessibility should match real human perception, not just satisfy a formula.

Color deficiencies

WCAG 2 and APCA focus on contrast between foreground and background. They do not check whether colors in your palette can be distinguished from each other.

For that, color hierarchy matters:

• Lightness matters most because it helps with fine details.
• Saturation comes next.
• Hue matters least.

A quick test is to switch your design to grayscale. If elements become indistinguishable, the palette needs adjustment. This also reveals whether your visual hierarchy is working—the most important thing should stand out the most.

Chrome DevTools can simulate vision deficiencies. Open DevTools (F12 or right-click and select Inspect from menu), go to the Rendering tab, and use “Emulate vision deficiencies.” It helps you quickly see how your UI behaves for different users.

One of the best external tools we've found is Coloring for Colorblindness by David Nichols. It shows multiple types of color vision deficiencies at once.

Beware of too much contrast

Extreme contrast is not always better. For example, pure black (#000000) on pure white (#FFFFFF) may sound ideal, but often causes eye strain. The sharp jump in brightness can lead to fatigue or a shimmering effect (halation), especially during long reading sessions. Softer combinations—such as off-black text on white or slightly muted backgrounds—are gentler on most people's eyes.

Applying color standards in OrgPad's palette

Color in OrgPad is everywhere. Cells, text, links, buttons, and backgrounds all interact. Every combination needs to stay readable.

Checking this manually would be slow and error-prone, so we automated it. We wrote simple Clojure code that evaluates contrast across the system. It checks combinations such as:

• heading text on cell backgrounds
• body text on cell backgrounds
• buttons and icons against surroundings
• cells against the canvas background

Each pair is evaluated using both WCAG 2 and APCA. This immediately shows what is safe, borderline, or problematic.

Here is the Clojure code for computing WCAG 2 contrast:

Similarly, this computes APCA contrast:

We feed these results directly into tables inside OrgPad.

This brings two key benefits. It speeds up development and improves consistency. Instead of guessing, we get immediate feedback on every color decision.

Dark mode in OrgPad is designed the same way as everything else. Accessibility is built in, not added later as a last-minute fix. And code is one of the tools we use for design, not just for implementation. But that would deserve a whole article of its own.

Dark mode colors in CSS

This is where dark mode moves from design into implementation. For a simple website, such as a blog, dark mode can be handled entirely in CSS. You can use the prefers-color-scheme media query to override colors when dark mode is preferred:

For anything larger, this approach does not scale well. Instead, it is better to define a color palette using CSS variables.

We define variables for light mode on the :root element. When dark mode is preferred, we override them with dark equivalents. All styles then use these variables.

Adding color theme to settings

For an application, we want to add the color scheme into settings. The default follows the browser, but user can still override this choice. There are three options: system default, light mode, and dark mode.

When system default is selected, we watch for changes and update the color scheme accordingly.

This can be easily achieved in JS. To detect preferred color scheme, we can use window.matchMedia function. In OrgPad, we store the selected mode both per device and per user. Here is our ClojureScript code which initiates color scheme in OrgPad:

To watch for changes in preferred color scheme, we can add an event listener to the MediaQueryList object. It just calls the init function again.

When the user changes the color scheme manually, we update app's color scheme, store the new choice locally at the client and also send the new value to the server via WebSocket messages:

Updating the current color scheme

It remains to show what happens when app's color scheme updates. Since OrgPad's rendering process is quite involved, we have to update it in several places:

• First, we store the new color scheme in Re-frame DB. Re-frame and React then pick it up and update all components that depend on it.
• We also store it in Frame-anim, a separate component doing most of OrgPad's rendering, as we described earlier in this blog post. Rendering is prepared frame by frame using the window.requestAnimationFrame function. Frame-anim handles spring animations, frame geometry, and rendering of the current frame on a 2D canvas. In other words, it knows which cells and links are currently visible, manages their animated state, and draws the scene. When switching the color scheme, it resets all canvas cell caches, updates colors in all spring animations, and redraws the scene.
• Last but not least, we use a static CSS file to define the look of most of UI components. In dark mode, we add the dm class to the root <html> node. In light mode, we remove it.

Light and dark mode palettes in CSS

In OrgPad's CSS file, we use the same trick of having different color palettes for light and dark mode. But instead of a media query, it depends on existence of the dm class.

Then we use these variables everywhere. For example, we style Material-ui blue button like this. We have to use !important everywhere since Mui is injecting their styles into CSS with higher precedence.

The second example shows how to define relative CSS colors, based on values in a variable. In this case, it overrides the alpha channel to 0.08.

Generating CSS with Garden

OrgPad generates CSS from Clojure using the Garden library. As we have already mentioned, all OrgPad's colors are stored in the colors map, described in okLCH and converted to RGB hex codes at compile time. We use this map everywhere in the code, including when generating static CSS with Garden.

CSS color palettes are generated like this using the unified OrgPad's color palette we have shown before:

And we have the following helper function for using color variables:

Then aforementioned colors for buttons are specified like this:

And it is called for all button color schemes:

Inverting colors in math and chemistry

OrgPad uses Mathjax to render math and chemistry formulas. We process LaTeX sources on a secondary Node.js server running MathJax. It outputs SVG images together with their dimensions, which are then inserted into cells.

For example, the Pythagorean equation  with the source a^2 + b^2 = c^2 produces the following SVG image:

All the letters are rendered black, which works well in light mode. But in dark mode, the equation won't be visible.

Inverting colors in CSS

For HTML rendering, we can easily fix it with the CSS filter property. In particular, it can invert colors, rotate hue, change contrast, and more.  For example,  invert(1) turns

so it flips black and white. Unfortunately, it also changes yellow #FFFF00 into blue #0000FF, instead of a darker yellow. Luckily, we can combine it with hue rotation.

After I was experimenting with different combinations, I found that this works really well:

For example, it turns the full yellow #FFFF00 into a dark yellow/olive #6A6A00.

To apply this filter selectively only in dark mode, we define it as a CSS variable inside dm class:

Then we can use it for all math formulas. In OrgPad, these images have the custom data attribute data-math-id:

Here is the result for a cell about Pythagorean Theorem with three sides highlighted in different colors. It looks really good.

Inverting colors in 2D canvas

In OrgPad, most cells are rendered using a 2D canvas because it is much faster, looks better, and uses less memory than browser's DOM rendering.

For this rendering, we prerasterize SVG math formulas into offscreen canvas images. These are then drawn either into the onscreen canvas for the current frame or into offscreen canvas caches for individual cells. In dark mode, we therefore need a way to rasterize inverted math formulas.

Couldn't we just use ctx.filter property which works exactly as CSS filter property? Unfortunately, ctx.filter is not supported in Safari at the moment.

Luckily, we can achieve the same effect with SVG filters. Here is the dark mode version of the previously shown Pythagorean equation with highlighted changes:

The modified SVG image first introduces a new dm filter which inverts the colors. It works in four steps, exactly as CSS --math-filter described before:

1. Inverts colors with the coefficient 0.7.
2. Rotates hue by 180 degrees.
3. Increases brightness by 1.2.
4. Increases contrast by 1.2.

Then the dm filter is applied to the entire SVG by wrapping it with <g filter="url(#dm)">.

We generate these dark mode SVGs dynamically in OrgPad's ClojureScript code. First, we describe the dm filter in Clojure Hiccup syntax:

Then we turn it into an HTML string:

Finally, we just insert the dm filter into an input SVG string. Note that we are converting the original size in ex units, generated by MathJax, into canvas pixels; otherwise SVG rasterization in Safari looks horrible.

Our solution is a little bit hacky. It relies on the particular structure of SVGs generated by MathJax, doing string and regexp replacements. A more robust approach is to parse SVG into Hiccup, transform it there, and then convert it back into an HTML string.

Here is the cell about the Pythagorean Theorem rendered into a 2D canvas. If you don't notice any difference, that's a good sign. We wanted both renderings to look as close to each other as possible.

Inverting other images

We cannot apply the same approach to user uploaded images. For example, we usually do not want to modify photos at all. Still, some images can look quite bad in dark mode, especially when placed directly on the background canvas.

Our solution is to let users choose an alternative version of the image for dark mode. In the editor, we even provide a quick generator for creating such images.

We use a similar idea here as well: we wrap an arbitrary image with a dm SVG filter. We first download the processed image in JS and convert it to a base64 string. This is done by the following Re-frame effect:

We then generate an SVG image with the dm filter for the selected values of invert, hue-rotate, brightness, and contrast. The SVG contains the converted image as a base64-encoded <image> element.

When the user clicks the generate button, we create a canvas of the correct size, rasterize the SVG image into it and save the result to the server.

It would not be much more difficult to add a basic image editor to OrgPad, and it would be very useful. We definitely plan to add one in the future.