{"id":5519,"date":"2025-04-10T10:59:27","date_gmt":"2025-04-10T15:59:27","guid":{"rendered":"https:\/\/frontendmasters.com\/blog\/?p=5519"},"modified":"2025-04-22T13:31:19","modified_gmt":"2025-04-22T18:31:19","slug":"using-currentcolor-in-2025","status":"publish","type":"post","link":"https:\/\/frontendmasters.com\/blog\/using-currentcolor-in-2025\/","title":{"rendered":"Using currentColor in 2025"},"content":{"rendered":"\n

Gotta give props to currentColor<\/code>. It’s a keyword in CSS that is the OG variable<\/em>. It wasn’t always<\/em> there, but it was relatively usable in browsers by, say, 2010.<\/p>\n\n\n\n

currentColor<\/code> is a value, that you have control over, that represents something else.<\/p>\n\n\n

.card<\/span> {\n  color<\/span>: red;\n  border<\/span>: 3px<\/span> solid currentColor;\n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
What do you think the color of that border is gonna be? Not a trick question, it’s red<\/code> my friend. You don’t have to type red<\/code> 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.<\/p>\n\n\n\n
The value currentColor<\/code> resolves to is whatever the color<\/code> value resolves to at the element being effected by the selector. The color<\/code> 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.<\/em><\/p>\n\n\n\n
p.s. it can be currentColor<\/code>, currentcolor<\/code>, CURRENTCOLOR<\/code>, cUrrENtCoLOr<\/code> or whatever. CSS is unbothered. Just spel it right.<\/p>\n\n\n\n
Hard Times<\/h2>\n\n\n\n
Business just isn’t rolling in thick anymore for currentColor<\/code>. 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.<\/p>\n\n\n
.card<\/span> {\n  --mainColor<\/span>: red;\n \n  color<\/span>: var<\/span>(--mainColor);\n  border<\/span>: 3px<\/span> solid var<\/span>(--mainColor);\n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
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. <\/p>\n\n\n\n
Versatile?<\/h2>\n\n\n\n
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<\/code> only references color. There is no currentPadding<\/code> or currentEmotionalState<\/code> or anything.<\/p>\n\n\n\n
Bugs?<\/h2>\n\n\n\n
I figured I’d have a play<\/a> for old times sake. While I was doing that, I noticed a few oddities. <\/p>\n\n\n
body<\/span> {\n  color<\/span>: orange;\n  accent-color<\/span>: currentColor; \/* doesn't work \ud83e\udd37\u200d\u2640\ufe0f *\/<\/span>\n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
That one just doesn’t work (across the three major browsers I tried). Why? No I’m asking you.<\/em> lol.<\/p>\n\n\n\n
Here’s another:<\/p>\n\n\n
body<\/span> {\n  color<\/span>: rebeccaPurple;\n}\nbutton<\/span> {\n  border<\/span>: 1px<\/span> solid currentColor;\n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
That one isn’t a bug, I suppose, as the trouble is that user agent stylesheets tend to set the color<\/code> of buttons themselves (e.g. color: buttontext;<\/code>), so if you want it to work, you’ll have to set the color explicitly, or force inherit it.<\/p>\n\n\n
button<\/span> {\n  color<\/span>: inherit;\n  border<\/span>: 1px<\/span> solid currentColor;\n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
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. <\/p>\n\n\n\n
I will say that using currentColor<\/code> with the relative color syntax is awesome, like:<\/p>\n\n\n
a<\/span> {\n  color<\/span>: orange;\n  text-decoration-color<\/span>: oklch<\/span>(from currentColor calc(l + 0.1<\/span>) c h \/ 90%<\/span>);\n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
But is it still cool though?<\/h2>\n\n\n\n
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<\/code> should always match the text color. That’s a fine use case really. <\/p>\n\n\n
nav<\/span> {\n  color<\/span>: salmon;\n\n  svg.icon {\n    fill<\/span>: currentColor;\n  }\n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
Another step further, we could pop a little shadow on those icons that is based on that color. <\/p>\n\n\n
nav<\/span> {\n  color<\/span>: salmon;\n\n  svg.icon {\n    fill<\/span>: currentColor;\n    filter<\/span>: drop-shadow<\/span>(\n      0<\/span> 1px<\/span> 0<\/span> oklch(from currentcolor calc(l - 0.25<\/span>) c h));\n  }\n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
Here’s a video of that and some other stuff working together. No custom properties here, all currentColor<\/code>:<\/p>\n\n\n\n\t\t
\n\t\t\t
 
Which is basically what I was doing in Chilled Out Text Underlines<\/a>.<\/p>\n\n\n\n