The assumed basic HTML and CSS

Up to you exactly how to include and structure it, but all the examples that follow assume something like this:

<fieldset>
	<legend>Theme</legend>
	<label><input type=radio name=theme id=theme-auto checked> Follow system</label>
	<label><input type=radio name=theme id=theme-light> Light</label>
	<label><input type=radio name=theme id=theme-dark> Dark</label>
</fieldset>

I’m going to assume the availability of a few CSS features:

1. @media (prefers-color-scheme: dark) for automatic selection.
   It shipped in 2019–2020, which is generally enough.

2. :has() for manual selection without needing additional JavaScript.
   It’s newer, supported back to 2023-12;
   I consider that enough to rely on in general,
   but if you’re not happy with it, you have two options:

   1. Only support one behaviour (probably auto) sans-JS.
      This is a very reasonable choice.
      You might add a light or dark class to the root element.
   2. Shift the radio buttons to be direct children of the body, hiding them visually,
      and then target #theme-foo:checked ~ * …
      instead of :root:has(#theme-foo:checked) ….
      Messy and with some consequences and inconveniences, but generally possible.

3. I will also use nested selectors in some places in this article (2023-12);
   but they’re easily flattened if you wish.

1. Write it all out the hard way

Old-school and verbose.

• The most compatible.
• It’s easy to see how to add more themes than just light and dark.
• Syntax is verbose.
• Dark theme value has to be repeated.

some-element {
	color: darkred;

	:root:has(#theme-dark:checked) & {
		color: pink;
	}

	@media (prefers-color-scheme: dark) {
		:root:has(#theme-auto:checked) & {
			color: pink;
		}
	}
}

It’s often structured differently, with the nesting effectively inverted as in the next example,
but that’s the gist of it.

2. Lots of colour palette variables

Probably the most popular approach, traditionally.

Though I was surprised to realise the implementations only landed in 2014–2017.
Sure feels longer ago than that. But it still feels okay to call it “traditional”,
because people often used Sass variables to similar effect before.
(You didn’t often have multiple themes in those days.)

• Works since 2017-04.
• It’s easy to see how to add more themes than just light and dark.
• Use-site syntax is ideal.
• Separating colour definitions from their use location may help or hinder,
  and may or may not fit nicely into your project.
  It can encourage some bad and some good patterns, and may yield a little more overhead.
  (I’m being vague deliberately, and will not elaborate here.)
• Dark theme value has to be repeated.

The declaration:

:root {
	--color-somepurpose: darkred;
	--color-another: …;
	⋮
}

:root:has(#theme-dark:checked) {
	--color-somepurpose: pink;
	--color-another: …;
	⋮
}

@media (prefers-color-scheme: dark) {
	:root:has(#theme-auto:checked) {
		--color-somepurpose: pink;
		--color-another: …;
		⋮
	}
}

Adding more themes is trivial.

And use site:

some-element {
	color: var(--color-somepurpose);
}

You can also obviously use variables for most of the remaining approaches.

3. The space toggle hack

• Works since 2017-04.
• It’s easy to see how to add more themes than just light and dark.
• Use-site syntax is not bad, but it is strange.
• Every use must enumerate every theme (no inheritance or else branch).
• The feature is somewhat confusing, and will feel back to front.
• Tooling and formatters may be incompatible with the trick
  (though most tools will be canny to it by now).

This is poor man’s if() (which actual function we’ll get to).
You get a single-branch conditional spelled var(--condition, value).
Honestly it’s not really worse than if() for cases like this, just different.

It works because of a frankly ridiculous implementation detail in Custom Properties.
I’ll defer to Lea Verou for further explanation.

At the start of the stylesheet:

:root {
	--light: initial;
	--dark: ;
}

:root:has(#theme-dark:checked) {
	--light: ;
	--dark: initial;
}

@media (prefers-color-scheme: dark) {
	:root:has(#theme-auto:checked) {
		--light: ;
		--dark: initial;
	}
}

And use site:

some-element {
	color: var(--light, darkred) var(--dark, pink);
}

And voilà: if light, darkred; if dark, pink.

It’s not a popular technique, and I forgot about it when compiling this list.
But someone reminded me after publication, so I added it:
it’s worth considering, especially if you want longer compatibility,
because it and variants really do work rather well.

4. color-mix() with one variable per theme

I don’t recall encountering this technique before
(actually I’ve been surprised at how little attention color-mix() has been paid),
but it works.

Basically, define a colour as a mixture of all the colours across all themes,
but use a variable to set one of the themes to 100% and the rest to 0%.
(In practice, you’re normally just using two themes: light and dark.)

• Works since 2023-05.
• It’s easy to see how to add more themes than just light and dark.
• Syntax is reasonably compact.
• Syntax is likely to be unfamiliar, but is fairly straightforward.
  Pity about the interpolation method part that’s currently necessary.
• Opens up interesting ideas for actually mixing colours/themes.
  What does --dark: 50%; mean?
  You can play around with the consequences 🎨 Aa on this site!
• If you do try mixing colours and themes, controlling interpolation is a pain;
  you have to figure out how to express your desired function mathematically.

This is the technique I settled on for my own site,
because once I realised the potential,
I wanted to play around with mixing themes.
I’ve started writing more about it.
It’s more interesting/involved than you might imagine.

At the start of the stylesheet:

:root {
	--dark: 0%;
}

:root:has(#theme-dark:checked) {
	--dark: 100%;
}

@media (prefers-color-scheme: dark) {
	:root:has(#theme-auto:checked) {
		--dark: 100%;
	}
}

Then with each colour we can use color-mix() like so:

some-element {
	color: color-mix(in oklab, darkred, pink var(--dark));
}

And it will be darkred in light mode and pink in dark mode.

Mostly you only care about changing colours,
but if you wanted to change other things based on the theme you could,
by making the variable a number instead of a percentage, and using calc().
(Without having thought through the implications—
I wish percentages and numbers were unified, with 100% equivalent to 1.)

:root {
	--grass: 0%;
	--ocean: 0%;
}

:root:has(#theme-grass:checked) {
	--grass: 100%;
}

:root:has(#theme-ocean:checked) {
	--ocean: 100%;
}

some-element {
	color: color-mix(in oklab, color-mix(in oklab, color-mix(in oklab,
		darkred,
		pink var(--dark)),
		green var(--grass)),
		blue var(--ocean)
	);
}

	color: color-mix(in oklab,
		darkred,
		pink var(--dark),
		green var(--grass),
		blue var(--ocean)
	);

5. light-dark()

• Works since 2024-05 (Safari 17.5).
  This just barely satisfies my preferred compatibility requirement,
  “two years of Safari and a year and a half of the rest”.
• Can’t use it for more or other themes than just light and dark.
• Syntax is compact and clear.

To begin with, you must set color-scheme properly.
You should do this with all of the techniques,
for a few reasons such as scroll bar and form element colouring,
but with light-dark() it’s necessary for it to work at all.

:root {
	color-scheme: light dark;
}

:root:has(#theme-light:checked) {
	color-scheme: light;
}

:root:has(#theme-dark:checked) {
	color-scheme: dark;
}

Then:

some-element {
	color: light-dark(darkred, pink);
}

6. if()

• Only implemented by Chromium family (2025-05); not yet supported on Firefox or Safari.
• It’s easy to see how to add more themes than just light and dark.
• Syntax largely matches programmer expectations,
• … but is fairly verbose.

See also the space toggle hack, which is slightly less general than this,
but frankly similarly expressive for colour purposes, and less verbose.

At the start of the stylesheet:

:root {
	--theme: light;
}

:root:has(#theme-dark:checked) {
	--theme: dark;
}

@media (prefers-color-scheme: dark) {
	:root:has(#theme-auto:checked) {
		--theme: dark;
	}
}

Then with each colour use:

some-element {
	color: if(
		style(--theme: light): darkred;
		style(--theme: dark): pink;
	);
}

This is differently flexible than color-mix():
color-mix() is limited to colours only, and allows continuous interpolation;
if() works on all types, but is limited to discrete values.

Adding more themes is trivial based on what has already been shown.

7. Paused @keyframes animation

This is a tricky technique I’ve seen applied occasionally,
but I don’t remember ever seeing it used for colours.

Instead of probably defining colour palette variables,
define colour palette keyframes rules (one per property you use it with!),
where “from” means light mode and “to” means dark mode.
Then at use sites, add a paused animation,
and in dark mode apply a negative delay to put the animation at the “to” (dark) value.

• People will think you crazy. There’s an above-average chance they may be right.
• Works since 2020-01 (when Edge adopted Chromium; other than that it’d be 2013-07).
• As with color-mix(), the technique begs you to allow mixing colours/themes!
• If you really want to blend themes, you won’t get better than this for controlling interpolation.
  (It’s almost like it was designed for it!)
  (Though… keyframes are not always better than mathematical functions.)
• Unless you have no other animations, you’ll be stuck with a lot of repetition,
  and some really painful composition of animation declarations.
• I bet you’ll run into specificity-style troubles somewhere along the way,
  because animations are even more powerful than !important.

@keyframes color-somepurpose {
	from { color: darkred; }
	to { color: pink; }
}

some-element {
	animation: 1s paused color-somepurpose forwards;

	:root:has(#theme-dark:checked) & {
		animation-delay: -1s;
	}

	@media (prefers-color-scheme: dark) {
		:root:has(#theme-auto:checked) & {
			animation-delay: -1s;
		}
	}
}

I’m not going to explain this one further;
if you don’t understand it, it’s probably for the best—
or else take it as a challenge.

New direction

I have Ideas.

🚧 Under construction 🏗️

Do you remember those “under construction” banners and GIFs of the ’90s (loads 941 images totalling 9 MB)? They tend to depict a work site and the notion of caution or danger.

A building construction zone is a dangerous place: there will be things to trip over, fall into, and have fall on you.

Children may still want to play there, because things are interesting.

A website construction zone is a place where you can safely poke and prod.

This site is very much under construction. Come take a look! view-source: everything! Have fun!

Oh? You say it all looks minified? Turn on dev mode in the 🎨 Aa prefs panel (or set the cookie dev=1 by some other means) and the server will give it to you unminified.

Glimpses of my plans

What’s implemented so far doesn’t actually reflect my ultimate plans very well—it’s still comparatively traditional.

I also haven’t integrated my own lightweight markup language into it yet, although it will be central in the long run. But although I’ve been doing all my writing in it for five years, I only got serious about implementing it last year and haven’t finished.

You’ll see my grand plan as it unfolds, but I’ll mention a few things:

• Full pure-CSS 3D environment. Content will be integrated into this.
• Interface reminiscent of a point-and-click adventure (where screen size permits).
• 3D, page-turning books that work better than any demo you’ve ever seen (including things like your browser’s find-in-page actually working, taking you to the correct page).
• Handwritten/-drawn content (don’t worry, as accessible as I can make it, and you’ll generally be able to opt for regular text if you don’t like my handwriting, though it might lose panache or a little more).
• A pipe organ (which will, alas, require some JavaScript). Turns out you can synthesise a surprisingly realistic pipe organ in surprisingly little code, under a hundred lines with the Web Audio API. Like physical pipe organs, the actual sound is the easy part, it’s the orchestration of keys, stops, ranks and such that’s… not even hard, just fiddly.
• Multiplayer experiences, including me idling in the virtual space a lot of the time, contactable by visitors. (I have plans that will build on this concept and do very useful things with it. Realism suggests I won’t get that far until at least 2028.)

Something I made a decade ago

It was a small part of an idea I had for an about page, partly to do with getting a job. I never actually shared it anywhere. Other than changing mouseover/mouseout to mouseenter/mouseleave (almost enough to tick off “Fix all the weird glitches with it”) and a few small tweaks to reconcile it with my site styles (including namespacing classes to this page, for future compatibility), I have not modified it at all. I would implement it better now, especially around making it render better when zoomed in. Click on it! Hover the clock! Sorry mobile users, it won’t work particularly well for you.