<input 
  type="color" 
  value="oklab(59% 0.1 0.1 / 0.5)" 
  colorspace="display-p3" 
  alpha
>

I was able to make a quick demo and see it on iOS:

Under the Sliders tab, it’s still just R G & B, but it seems to me you can produce colors still in the P3 space. And if you’ve set the color space, it gives you a P3 hex code there (which I didn’t even know was a thing honestly). The actual value that you get is like: color(display-p3 0.921957 0.31855 0.969179). Which I guess is fine? Just don’t expect to get out a color in the same format you put in.

Safari also displays the alpha transparency in the preview color chip, which is great to see. This might be tricky to actually use right away, depending on what you’re doing, as non-supporting browsers will see the value as invalid and display/return black/#000000

currentColor is a value, that you have control over, that represents something else.

.card {
  color: red;
  border: 3px solid currentColor;
}

What do you think the color of that border is gonna be? Not a trick question, it’s red my friend. You don’t have to type red twice. You don’t have to worry those colors that you’ve so elegantly tied together are going to drift apart. The power of computer programming lives here.

The value currentColor resolves to is whatever the color value resolves to at the element being effected by the selector. The color property cascades, so it could be set three levels up from the current element, or not at all, or whatever. It’ll always be something.

p.s. it can be currentColor, currentcolor, CURRENTCOLOR, cUrrENtCoLOr or whatever. CSS is unbothered. Just spel it right.

Hard Times

Business just isn’t rolling in thick anymore for currentColor. Search a 10 year old codebase and you’ll find a few hits, but these days, custom properties are a far more popular choice. Are you turning your back on an old friend? Yes. Is new friend better? Also yes. Just saying.

.card {
  --mainColor: red;
 
  color: var(--mainColor);
  border: 3px solid var(--mainColor);
}

This does the same thing. It’s an extra line of code, but your fellow computer programmers will all agree that it’s much more clear and versatile.

Versatile?

Definitely. Custom properties can be just about anything. It’s almost weird how permissive the value of a custom property can be. But it’s certainly not just colors. Hopefully obviously: currentColor only references color. There is no currentPadding or currentEmotionalState or anything.

Bugs?

I figured I’d have a play for old times sake. While I was doing that, I noticed a few oddities.

body {
  color: orange;
  accent-color: currentColor; /* doesn't work 🤷‍♀️ */
}

That one just doesn’t work (across the three major browsers I tried). Why? No I’m asking you. lol.

Here’s another:

body {
  color: rebeccaPurple;
}
button {
  border: 1px solid currentColor;
}

That one isn’t a bug, I suppose, as the trouble is that user agent stylesheets tend to set the color of buttons themselves (e.g. color: buttontext;), so if you want it to work, you’ll have to set the color explicitly, or force inherit it.

button {
  color: inherit;
  border: 1px solid currentColor;
}

I also swore I found an issue with relative color syntax and currentColor, but now that I’m typing and fact checking I can’t find it again so I’ll just leave it at that.

I will say that using currentColor with the relative color syntax is awesome, like:

a {
  color: orange;
  text-decoration-color: oklch(from currentColor calc(l + 0.1) c h / 90%);
}

Which is basically what I was doing in Chilled Out Text Underlines.

But is it still cool though?

I feel like I’ve made the point that it’s not amazingly useful anymore, but I might also argue that it’s not a terrible idea when the intentionality matches up just right. For instance, say you’ve got icons where the fill should always match the text color. That’s a fine use case really.

nav {
  color: salmon;

  svg.icon {
    fill: currentColor;
  }
}

Another step further, we could pop a little shadow on those icons that is based on that color.

nav {
  color: salmon;

  svg.icon {
    fill: currentColor;
    filter: drop-shadow(
      0 1px 0 oklch(from currentcolor calc(l - 0.25) c h));
  }
}

Here’s a video of that and some other stuff working together. No custom properties here, all currentColor:

I have stuck in my memory a Simurai post from 2014 where he showed off the power of this as well.

background: linear-gradient(
  to right, 
  red,
  red 50%,
  blue 50%,
  blue
);

To turn that into stripes, we can set the background-size smaller and let it repeat. But perhaps the more-correct tool is to use repeating-linear-gradient() which automatically handles, ya know, repeating the gradient.

background: repeating-linear-gradient(
  #d84315,
  #d84315 10px,
  #fbc02d 10px,
  #fbc02d 20px
);

I think it’s a bit lesser-known, but there is an updated syntax to gradients where you can list two color stop lengths instead of just one, so the above code actually can get a little simpler:

background: repeating-linear-gradient(
  #d84315 0 10px,
  #fbc02d 10px 20px
);

OK that took me a minute to get to the point lol.

It occurred to me that these hard-stops can work for conic-gradient() as well. I was literally trying to make a burst background and was pleasantly surprised when I tried this and it worked.

background-image: repeating-conic-gradient(
  black 0deg 10deg,
  #666 10deg 11deg
);

I was actually trying to set some text in the middle, so I wanted to start the burst away from the center. Easy enough with a radial gradient sitting on top of it.

While I was thinking about this, I happed to see the Robinhood homepage and it was pretty burstin’.

See how that burst has lines breaking it up. I bet you could figure out how to do that by laying on more radial gradients, or perhaps a repeating radial gradient with transparent color stops.

Ughgkgh fine I’ll do it.

But I’ll let you figure out how to animate that. I bet you could do it with @property on some custom properties that you sneak into those gradient definitions.

This also reminds me that I worked on some bursts one time that were a bit more randomized using SVG. Feel free to click to reset what’s going on below:

We have a ton of “newly available” power in CSS with this in the form of the relative color syntax, and Ahmad’s new post about this is great. The color-mix() function has a bit better browser support and has a good amount of overlap in what it can do, but I prefer the syntax and power of the relative color syntax.

What if I told you that #ff0000 or rgb(255, 0, 0) is not actually the reddest red you can have in your browser?

Here’s what that’s like in macOS Chrome:

The UI varies, but in all cases it doesn’t actually show you the color value you’ve picked when the picker is closed. I think that’s… weird? What if the input is part of a form in which you actually have a valid color you want to put in yourself? Or copy the value out of?

I thought of this while I was looking at Adam Argyle’s color-mix() tool. It’s a great tool, but it made me wish I could just type or paste in a color rather than having to use the picker.

I figured I’d toss together a Web Component that would actually display the color. We could call it an HTML web component as it starts with perfectly valid HTML (which you can customize as needed) then you wrap it in a custom element to extend the functionality and/or UI. In this the thing that displays the color is an <input type="text">, because that works both to show it, and can accept a value that can propagate back to the color input.

That basically does what I was picturing. This keeps it all Light DOM so it would be quite easy to style and customize. Since could be used inside a <form>, you might need to fiddle with ElementInternals so that the input can participate in the form as expected. Since there are now two inputs that essentially have the same value, it’s likely you’ll only want one to submit as form data.

But my example there, like native color inputs themselves, deals exclusively in HEX colors. I was hoping that the text input could deal in any sort of valid color format.

Erick Merchant had a clever idea where the color from the text input is coerced into a HEX for the benefit of the color input, but otherwise accepts and valid color value. Try putting oklch(64.26% 0.3059 332) into this:

Pretty clever if you ask me! It won’t handle transparency, so that’s something to consider for sure, but otherwise seems to do a pretty good job. I’d be tempted to take the color inputs value in a form generally, as it has automatic validation to ensure it’s a valid color. But in the case of this second demo, I’d be tempted to take the text input value instead since it honors the original intention of the color, albeit very hard to validate.

1. It would be extremely cool if OS color pickers supported formats other than HEX as well as P3-and-beyond color spaces, but that’s a topic for another day. ↩︎

But here’s the thing: it just relies on your system preference.

(Or whatever is controlling what prefers-color-scheme is returning in your browser. I use the browser Arc sometimes and it’s Light/Dark modes override what is set in my System Preferences. It can get confusing.)

It’s more on-trend when offering color modes to offer users a toggle. That way users can easily choose between which they prefer without ever leaving your site. And they might have a preference that is the opposite of what their overall system preference is. Those are perfectly fair and legitment things.

Those things also complicate the work.

I think it’s also perfectly fair to make development choices that are purposefully uncomplicated.

In this case, choosing to support light and dark modes entirely within CSS alone was the uncomplicated choice.

The Basics

It really is just this:

html {
  --brand-red: oklch(0.67 0.24 27.98);

  --bg: black;
  --text: #ffdbdb;

  --link-color: #4ac6ff;
  --link-color-hover: #9ce0ff;
  --bright-color: white;
  --faded-color: #373232;
}

@media (prefers-color-scheme: light) {
  html {
    --bg: white;
    --text: #323232;

    --link-color: #068dcb;
    --link-color-hover: #67cfff;
    --bright-color: black;
    --faded-color: #dedede;
  }
}

Then steadfastly use those color variables everywhere any color is set.

The red stays the same across both. Fortunately red is fine with that.

The main point of modes is that most of the color should be dominantly dark or dominantly light, which is mostly about backgrounds. So the --bg background does the work there and the --text variable is an accessible color that sits on top of that background.

But it’s never quite that easy. You always need to need a couple of more colors, even on simple sites. So here I’m setting up variables for links and a couple of variations.

Purposefully simple.

I kinda like approach of just changing same-named --custom-properties myself, but there are alternatives. For instance you could use named colors (e.g. --my-gray-8) then use the now well-supported light-dark() function to do something like:

.card {
  background: light-dark(var(--my-gray-4), var(--my-gray-9));
  color: light-dark(var(--my-gray-9), var(--my-gray-1))
}

Why is offering a site-level toggle so challenging?

• The site level choice needs to override any other choice, so it means you can’t leverage @media very cleanly. But you still need to use @media for the default if there isn’t a choice, so you can’t back away from it entirely.
• You have to persist the choice, otherwise simply refreshing the browser could wipe away the choice, which is pretty weak sauce. Persisting data means at a minimum using localStorage or cookies, but you’d probably want to do better than that.
• The user choice can be different on the site than what their system or browser-level choice might be, so you need to load what that choice is before you render anything. Otherwise you risk Flash of inAccurate coloR Theme (FART) which is incredibly awkward.

I’d say it’s still worth doing if you’re working on a “big” site where you expect quite a bit of time-on-site from your users. You can also do something like I’ve done above as a first step and then move onto a toggle approach.

The Effect

I swear the change is much smoother than this (no thanks to transition or anything, macOS just makes it super smooth somehow). But when I was recording this video it wanted to be a more more abrupt 🤷‍♀️.

This was based on user-feedback, remember? Well one of those users noticed immediately and thanked Marc because it’s a better experience for them.