Chris & Shaw talk about a big ol’ conversion to getting CodePen’s color system to use --custom-properties all the way through, rather than Sass variables. Why? All sorts of reasons, kinda boiling down to the fact that they are just better. Here’s a tiny one: you can use the Web Inspector and see what some other element is colored easily. Here’s a huge one: ability to do theming way easier. But the refactoring isn’t without some bumps in the road, like the fact that CSS doesn’t have a way to alter colors (like lighten, darken, or add alpha) terribly easily yet, meaning we needed some work arounds.
Time Jumps
Sponsor: Retool for Startups
After working with thousands of startups, we’ve noticed that technical founders spend a ton of time building internal tools—which means less time on their core product. So, we built Retool For Startups—a program that gives early-stage founders free access to a lot of the software you need for great internal tooling.
The goal is to make it 10x faster to build the admin panels, CRUD apps, and dashboards that most early stage teams need. We’ve bundled together a year of free access to Retool with over $160,000 in discounts to save you money while building with software commonly connected to internal tools like AWS, MongoDB, Brex, and Segment.
We give you a head start with pre-built UI components, integrations, and other advanced features that make building from scratch much faster. To learn more, check out our site, apply, join webinars and much more at retool.com/startups.
Transcript
[Radio channel adjustment]
Announcer: Today, on CodePen Radio.
Chris Coyier: Hey, everybody. Time for another CodePen Radio. 334 here. We just pushed this live on Monday. We updated, and you'll notice nothing. That's our favorite -- at least at CodePen -- is the "Wow! A lot has changed, but you can't notice anything." It touched tons of files on the whole site. We're using CSS Custom Properties now (in a bigger way) and specifically for colors.
It's not like we only just use them for colors, but colors is a great use case of Custom Properties, and now we're using it pretty much everywhere. There are probably some that aren't quite there yet, but it was a pretty big, sweeping change toward Custom Properties.
Stephen did a lot of that work, so Stephen is here. What's up, Stephen?
Stephen Shaw: Hello, everyone.
Chris: Yeah, we just had this little idea to do it because we were using Sass before, and we're still using Sass now, so we had colors: red, green, blue, yellow - whatever. But we also had -- there are more of these: gray 1, 2, 3, 4, 5, 6, 7, 8, 9. But in our world, we had this kind of clever idea to call it gray, but then gray dark 1, 2, 3, 4, 5, and gray light 1, 2, 3, 4, 5. It was the split scale of grays, right?
Stephen: [Laughter] Yeah, and it worked decently well for us. I'm not exactly sure where it originated, but it would get confusing because gray light, you would go up to get lighter. And for gray dark, you would go up to get darker.
Chris: Up to go darker.
Stephen: There's just kind of like a weird mental juggle you had to do figuring out which direction you're trying to go.
Chris: Yeah. Yeah. Then even though it's light -- yeah. I never understood which one you would use for what. It does make some logical sense. It's just in reality, when I would reach for it, there'd always be this little moment of confusion.
But that's not even the main reason we switched away. There are a bunch of reasons we'll get into, but it also -- let's say, and we're not promising to ship this, necessarily.
Let's say we had a light theme site-wide. All of a sudden, those names don't make sense anymore because gray dark isn't dark anymore. You're flipping it to gray dark could be the lights, or something. You'd kind of paint yourself into a corner with those names.
Stephen: Yeah. Right.
Chris: Switching them out was one of the plans.
Stephen: There's this middle, like, gray variable that really wasn't used very much compared to all the other grays that I always found quite odd. But, yeah, switching over to a light theme. If we were to do that, since it's Sass variables, now I've got to retarget everything. We've got to add some media queries or different selectors for everything to now swap out gray dark 5 for gray light 4 or whatever the case would be. That's how some people do it, I guess. But that didn't seem very practical for how spread out our CSS and styles are.
Chris: Mm-hmm. I know one of the steps here was that we had the Sass variables and we use them a lot on the site. But at some point, we're like, "Let's just put in CSS property values also," and they just referenced the Sass variables. All it was, was a 1:1 mapping. You could kind of use whichever one you wanted. Use the Sass variable or use the custom property value. We did that because it was like, "Hey, why not?" Right?
But also, they're just more useful sometimes. For example, you can set an inline style on a DOM element that uses a custom property and that will just work, where you can't do that with Sass. They have some superpowers in that way that made them useful.
But now we have two places that these variables are, and I think that was the genesis of the project is like, "Uh... That's probably not the world's greatest thing to just have half and half of your colors use variables; half and half -- no good.
Stephen: Yeah. A lot of this started with the button component that we were doing. We switched over a lot of our buttons from just a button class to an actual React button component. Then as we started using that around our different packages and everything like that, we were having trouble with global styles, so we started modularizing everything and getting that going.
Then we were running into different issues with getting buttons to be the color you want or slightly adjusting button colors for the header versus the footer - all these little things that CSS Custom Properties ended up being a great solution for. We kind of got into doing those for the button component, and so we ported the colors over to custom properties so we could reference them easily there and easily make a button green or whatever. Changing the size of buttons and the margins and all that.
And so, this kind of set us down the path of, "Well, how can we make this a little more useful across the site with our colors, for sure, but also just other uses of variables: sizes of things, font families, all that kind of stuff?" Theming being one of the big use cases because we do have themes currently in the editor.
Chris: Mm-hmm.
Stephen: That are very, very targeted CSS files that change a bunch of the global classes and target things in a weird way that we wanted to come up with a better system for to make theming easier in the future.
Chris: Yeah, that is part of this, isn't it? As we work on new features of CodePen, it's kind of like we need to support or we'd like to support the things that we already do support. The fact that there are themes in the editor, why bring over all that old crap? That, like, "Oh, you picked a light syntax highlighting theme for your editor. We're going to make the header and the footer and, as much as we can in the UI, also be light so it doesn't just feel super awkward that just the little code editor areas are light theme but the rest of the entire editor is dark theme."
[Laughter]
Chris: That was done so long ago that there was no good way to do it. It was just kind of like, "Oh, body.light-theme? I'll just write 50 selectors of all the things that I need to turn white and turn them white." You know?
Stephen: Yeah.
Chris: That's not very hip anymore. It's not the way to do it. The way to do it is to set colors with custom properties. Then when you're in a light theme, just flop out the custom property and watch that just beautifully kind of cascade throughout the site. Let's do that instead.
Then it becomes not just the editor then that's being changed but, theoretically, the whole site. Again, we're not around the corner for shipping light mode on CodePen or anything like that.
But it's not just light mode, either, as Stephen pointed out many times as we worked on this. It's like, what if you want super cool orange mode or sepia mode, old-time-y mode or whatever? You've kind of got to think in those terms so that you don't name things again dumbly. You know?
Stephen: Right.
Chris: It's just a theme.
Stephen: Yeah. It's not necessarily gray, like in the case of the solarized color theme that's pretty popular, or midnight kind of code themes that uses more of a blue hue rather than just a straight gray. And solarized uses these kind of like orangey tones.
You want to name something so that you're not having to do mental gymnastics to figure out which color you're referencing for this specific theme. You want it to be kind of just a universal scale of sorts.
Chris: We didn't use gray in the variable names, right? It's just like CP theme color 1, CP theme color 2, or something like that.
Stephen: Well, we shortened it even further, so one of the things we did with this change was kind of prefixing all of our global CSS variables to kind of namespace everything. We've got the dash dash (--) that you always see in front of a custom property that declares it a custom property, and CP and then another dash and then whatever it is.
For the most part, all of these are --CP-color. Then for our main color scale for translating from gray light 7 to gray dark 8 - or whatever it was - there were roughly 20 different shades that were available.
Now, instead of gray light 7 - or whatever - it's --CP-color1. It goes from 1 to 20 with 1 being the most dominant or prominent and then 20 being the most subtle, so kind of fading along those lines.
Chris: Yeah. Cool. That worked, and that was a whole lot of RegEx, finding and replace, and stuff because it touched something like 500 files, I think, right?
Stephen: [Laughter] Uh, yeah. I pulled up the PR here. It's 556 files changed.
Chris: Mm-hmm.
Stephen: Around 4,000 lines of code modified in some way.
Chris: That's a lot! That's too big for a PR. We try to not do that--
Stephen: Yeah.
Chris: --because it's hard to QA and stuff like that. But this project shifted in time because we had cut this into slices, smaller slices, like, "Oh, let's get rid of the Sass variables. Then we'll do this. Then we'll do that."
But there were a couple of those slices that would have touched the same amount of files, and it was one of those, like, "Yeah, but then you've got to QA it all twice and all that," so we ended up kind of rolling it together. It made it feel like a bigger release, but now it's kind of done.
Stephen: Yeah.
Chris: So, cool.
Stephen: Right. Yeah. Instead of multiple tiny or relatively tiny parts. We just kind of tackled it all at once. It's definitely a lot to go through.
Chris: Yeah.
Stephen: But it ended up being not too bad once I got the RegEx right.
Chris: If we were going to offer themes, it's not different. It actually will be a lot easier at this point. You have to think out the UX and the technology of that separately than just preparing for the themes like we've done now.
Stephen: Yeah.
Chris: Because there's, like, "What do you do? Do you put it in a cookie? Do you put it in a database? Do you put it in local storage? How do you avoid the flash of the wrong theme?" There are just all these little things you've got to think about. That might come later - or something.
Stephen: Yeah. Well, and there are lots of different areas that we offer theming, even currently, like the embed themes are currently not powered by CSS variables, really, or anything like that. But that's a perfect area that could benefit from this kind of format to make it easy for users to customize and all that.
Chris: I bet we could port what we have now to custom properties, probably.
Stephen: Right. I don't suspect that'd be too difficult, but that code is all ancient, so the embed theme builder itself needs a whole lot of love.
Chris: [Loud exhale]
Stephen: [Laughter] And users are also able to customize profiles. Right now, that's kind of a mess of custom CSS where you have to target very specific things if you wanted to change something's color. Now that we've kind of Reactized everything, targeting specific elements can be difficult because we're using CSS Modules, so the class names aren't as easy to find.
Chris: Uh-huh.
Stephen: And may change with a release based on the hashing or whatever.
Chris: I think the way we handled it is we put a human-readable class name on everything--
Stephen: Yeah.
Chris: --that was there before, so you'll always have that. We don't plan on changing it overnight. But to be honest, we're not that hip anymore about, like, "Just throw your own CSS on codepen.io," just because we do things to prevent anything nefarious from happening. But it's just not our favorite practice in the world.
Stephen: Yeah.
Chris: We're not going to change it overnight, but it would be easier to say, "Here's the 50 custom properties that you have access to that do all kinds of interesting things. That we can make safe--
Stephen: Yeah.
Chris: --in a way that is easier than regular CSS.
Stephen: Right, but that's theming. Of course, there are editor themes and all that. Now we've kind of established some ways to tackle those problems in the....
Chris: Yeah. Wow. There's theming all over CodePen.
Stephen: Yeah.
Chris: We're like a posterchild for theming, there are so many different aspects to it.
Stephen: It's the modern MySpace.
Chris: It's site-wide, but the embeds too, and your profiles, and syntax highlighting. It's like themes, themes, themes!
Stephen: Yeah.
Chris: So, that's cool. So, this is out. Why custom properties, again? Well, they have some superpowers. I just had one today that I found tremendously useful. I wanted to know. I was like, "Oh, this little element, when you're dragging it, needs to match this color over here. Let me look real quick and see what color that other thing was that I'm trying to reference."
Well, I'm so used to using the eyedropper or something and getting that color off of the thing I'm trying to match, but you can't just use the HEX color or RGB or HSL or whatever you get out of your color picker because then you're not using the variable. What I'd have to do is go into our colors file in Sass, find which one that was, and then use the correct Sass variable for it. There'd be this cross-referencing step to figure it out. You can't even find out from the DOM.
Stephen: Yeah.
Chris: Or the dev tools because it'll just be a HEX code there too. But now, you look in the dev tools and it'll tell you exactly what custom property it's using.
Stephen: Yeah.
Chris: That's just a nice developer experience, I think.
Stephen: It is, and the way you can trace CSS variables, now, in most dev tools. You'd click it and you can actually see where that property was declared or where that was overridden.
Chris: Yeah.
Stephen: There's just so many niceties to inspecting those now.
Chris: Yep. It, in a very general sense, feels futuristic in that CSS is big on these. They're going to evolve and get better. It just seems like the way to go.
Stephen: Yeah.
Chris: All that cascading ability, too, is useful - and stuff. But there's a little bit of rough edges here and there, so Sass has been around forever. I know one of the reasons some people reach for Sass originally is because they love the color manipulation abilities - if you're familiar with Sass and probably other pre-processors had these, too. I always had a feeling Sass was extra good at this.
They have a saturate function, lighten and darken, hue, and all this stuff. You could throw it any color value, and it would just manipulate that color. I used to use darken all the time.
Stephen: Yeah.
Chris: I feel a little guilty about that because I always heard there was something not color programming sound about darken, like it didn't -- it's not the same as mixing in black to the color for color nerds. You know what I mean?
Stephen: Yeah.
Chris: Whatever. I use darken anyway. I'd be like, darken 5% - or something. You do that because you wanted the same color as the background, but just a little darker because it's a horizontal rule - or something like that. You know? I want what we already have, but just a little darker - or something.
As I understand it, that's coming in CSS, but it's absolutely not here yet - not even under a flag or anything.
Stephen: Yeah.
Chris: Native CSS functions to manipulate colors that you pass it, that's going to be great. But because we don't have that, I think it's CSS color level 5 - or something like that.
We use Sass to do it and, all of a sudden, we switch away from Sass, and we're like, "Oh, crap." That was one of the "oh, crap" moments in this branch, wasn't it?
Stephen: Yeah. That took a lot of planning and trial and error to kind of get around. This is one of the big reasons that we ended up using HSL for the colors. HSL is just a way of defining the hue saturation and lightness of a color rather than just the HEX code that represents the RGB or the RGB function that kind of splits those out visually.
HSL, you can kind of natively do some of those changes you're talking about. Like if you wanted to adjust the lightness, you can just change how light or dark the color is without affecting the hue or the saturation. That's kind of nice.
Chris: Although, we didn't end up doing that, did we? Because part of it is like, don't you have 20 of these things? Why don't you just notch up? Why don't you go from 7 to 8? Doesn't that do the same thing - or 8 to 7 or whatever? It's like, yes, it does. So, that's the answer in our system for lightening and darkening, for the most part, but that doesn't solve this other thing, which is alpha, which also we needed.
Stephen: Yeah, and so one of the niceties in Sass is just being able to use RGBA or HSLA and giving it an alpha value, and then Sass would kind of automatically handle that or give it to the browser ready to handle that.
Chris: Oh, right, right, right, right. You can already do HSLA or RGBA in browsers, but then if you're doing it in native CSS, you need to know what the RGBA value is.
Stephen: [Laughter] Right.
Chris: But in Sass, you didn't have to. You could just pass it a variable or a HEX code or anything else.
Stephen: Any kind of color, yeah, and it would convert things, and so that worked really well. But our solution for that is doing essentially that same thing but just with native CSS. Rather than referencing the color directly, like HSL and then all the hue saturation and lightness variables, we actually define those hue saturation and lightness values in their own variable.
Where we've got --CP-color1, we also have --CP-color1-HSL.
Chris: HSL, right.
Stephen: That contains just those values, not wrapped in anything, not anything else, so that you can actually drop those in an HSL function in CSS and then adjust the alpha value after that. If you're inspecting the root of CodePen, you can see all of our CSS variables (if you're curious about any of these) and you can see how we're doing that.
--CP-color1 is actually just a little wrapper where it puts HSL around the --CP-color1-HSL variable.
Chris: Right.
Stephen: It seems kind of confusing [laughter] to talk about it, but essentially, pulling out those properties.
Chris: It just means you can use the color or you can use the parts of the color and add an alpha if you need to. That was useful. We ended up using it more than we thought we would, and it's nice. There are really two custom properties for every single 1 through 20 or 17 or however many we have.
Stephen: Yeah.
Chris: We could have done it -- it was discussed, "Why not spit out the H and the S and the L and have an HSL value?" You could keep breaking down this thing all the way down to the parts. There wasn't enough use cases to validate having five custom properties per color.
Stephen: Yeah.
Chris: It seemed like a lot.
Stephen: You've got to draw the line somewhere. [Laughter] In the future, I could see us doing that, or maybe even our whole theme scale being based around a single hue saturation and lightness variable setup (that 1 through 20) just kind of changes the values of that lightness.
Chris: Yeah. I see what you mean. Having a programmatically-based thing. That's not the case right now. Right now, 1 through 20 (or, again, 17, or whatever it is)--
Is it 20 or 17?
Stephen: It's 20.
Chris: It's 20 now. They're handpicked because I think our thinking is -- and I hope Klare would agree with us because she picked the colors originally -- there's a little bit of magic to colors.
Stephen: Yeah.
Chris: To make a really beautiful theme, it's not just rotate around color wheel, adding 15% for each value. That's okay. It's not going to be a disaster, but there's a little bit of artisticness to picking those colors.
Stephen: Yeah.
Chris: They're probably not exactly 15% on the hue wheel away from each other. One's a little more blue than the other one.
Stephen: If you're looking at our variable declarations, you can see that there are just slight adjustments. You can obviously see the lightness value going from 100% to 0%.
Chris: Mm-hmm.
Stephen: But the hue value, that degree of rotation around the color wheel of sorts, it's adjusting slightly for pretty much every shade. If we aligned them all to 220 degrees, or whatever, meh, it probably wouldn't be that noticeable of a difference. But giving them that slight hue adjustment helps each color fit together a little bit better.
Chris: Yeah, so that's how it will be for now, and it looks good. It gives them that extra good feeling.
Stephen: Extra grayness.
[Guitar music starts]
Chris: This episode is brought to you in part by Retool for Startups, so Retool, you know, retool.com, remarkably good tooling for building admin tools, internal tools, and stuff.
Retool for Startups is a special program that they're offering. This is what they say. After working with thousands of startups, they've noticed that technical founders spend a ton of time building internal tools -- been there -- which means less time on the core products.
They built Retool for Startups, a program that gives early-stage founders free access to a lot of the software they need for building great, internal tooling. The goal is to make it ten times faster to build admin panels, crud apps, and dashboards that most early-stage teams need.
They bundled together. It's a free year of access to Retool and then $160,000 of discounts for tools like AWS, MongoDB, Brex, Segment, you know, really popular tooling for building any kind of Web software, really. Use your Retool credits to build tools that join product and billing data together into a single customer view, tools that convert manual workflows into fully-featured apps for your team, tools that help non-technical teammates read and write to the database, and so much more.
It's retool.com/startups. That'll get you to the form to apply for this. There's some criteria for it, like you're less than five years old and things like that. Not you as a person, the company. You have to be over five years old as a person, I'm pretty sure. Check out the site, apply, join webinars, all that stuff - retool.com/startups.
[Guitar music ends]
Chris: All right. HSL for now, but I don't know that it's -- our system isn't exactly super-duper-duper defined by it. It wouldn't be that crazy for us to have done it in RGB or something.
Stephen: Yeah.
Chris: Because we're not really leveraging HSL, necessarily, which feels good to me. Speaking of future CSS stuff, there's other CSS (like color models or whatever) coming that are interesting because they, for example, are wider spectrum.
There was this early panic.com site that used some pink or something that was never seen before. It was a brighter pink than can be expressed in HSL or RGB or HEX.
Like, wow! Doesn't that blow your mind a little bit that there are these colors out there that monitors are capable of displaying that we just can't use [laughter] because our color model isn't there? That's mind-blowing to me.
Stephen: It reminds me of the days of Web-safe colors.
Chris: Yeah.
Stephen: Do you remember that? There was a palette of maybe 64 or 128 colors that that was all you were allowed to use, pretty much, because of compatibility.
Chris: Yeah. I remember the look of the Photoshop color picker when you turned that on.
Stephen: Oh, boy.
Chris: It would turn to these--
Stephen: Chunky shades.
Chris: Yeah. It was like a curve, like a parabola kind of thing, but they were overlapping each other, so there were only eight reds on any screen you could grab.
Stephen: [Laughter]
Chris: Um... yeah. That's cool. I like the inline style usage. I like the dev tool stuff. It feels like a nice thing to me. We're all set up for theming if we need it. Pretty cool. We solved that alpha problem - kind of neat.
I wonder. Did you end up keeping--? We ended up having a couple of little bonus properties that were darkened versions of it. Mostly with box-shadow in mind.
Stephen: Yeah. Right now, there's only one. CP color shadow is just kind of a general shadow that could be used. The thinking behind that is a shadow that's going to work on a dark theme is going to be different than a shadow that's going to work on a light theme.
Chris: Yeah.
Stephen: For a light theme, you want a more subtle shadow. It doesn't need to be as strong. If we just store that in a variable, then that can easily be swapped out.
Chris: Yeah. That's a good point. It really is awkward when you see a light theme flop over and then the shadows are white, too. You're like, "No, that's not right." They still should be darker.
Stephen: Right. But you don't want them too dark either.
Chris: Right.
Stephen: If it's too prominent of a shadow, that feels wrong too.
Chris: Right because on a dark theme, your shadows are probably as black you can make them.
Stephen: Right.
Chris: Otherwise, you can barely see the shadow at all. Yeah. You wouldn't want to continue that. Yeah, you need that kind of control. Yeah, little helpers here and there - don't matter.
There were a couple of other weird gotchas in it. One of them is that some of our stack is using Dart Sass, like latest and greatest, rock-n-roll, everything is cool. Some of our system is using literally Ruby Sass, which is old-old-old.
Stephen: Oh, yeah.
Chris: But we just aren't quite ready to rip it out yet or fight the fight that's necessary with basically Ruby on Rails and sprockets and the asset pipeline and all that. It's not that bad. Just leave it alone.
Stephen: Yeah.
Chris: But what was the problem? I think old Ruby has its own HSL function. So, if you use the modern CSS one, it gets overridden or something weird.
Stephen: Yeah. Pre-Dart Sass, Sass treated HSL as its own function rather than the native CSS HSL function. And so, I think it even (under the hood) converted your HSL declaration to a HEX. I think the reasoning behind that was browser compatibility because HSL historically has had some browser differences. I think we're in a better place with it now.
That presents a problem when you're trying to feed it a CSS variable because obviously, Sass doesn't have access to the CSS variable in the same way that the browser does, and it expected more than just one parameter. It expected a hue, a saturation, and a lightness to be fed in. So, getting around that was a little tricky because you basically have to tell Sass, "I don't want you to do anything with this."
Chris: Yeah. Just leave it alone.
Stephen: Just pass it through. So, I ended up writing just like a small, little override function. You've got @ function in Sass where you can declare a function, and I just @ functioned HSL, like overwrote theirs.
Chris: It just spits out whatever you give it.
Stephen: Right. It just does string escaping to make sure that that value is not handled by Sass at all. It just passes it straight through to the CSS.
Chris: That's cool. HSL is a native CSS function. It has been for a long time but has undergone changes as well. The modern CSS one, you're not even supposed to use commas anymore, and the alpha is just slash at the end of it. It's kind of a weird syntax. All the more reason to just have Sass leave it alone.
Stephen: Yeah.
Chris: Then we found a really weird one, which you found, which was that, in the Rails asset pipeline, it would run it through Sass, and then our asset pipeline was like, "Would you please compress our CSS too?" Rather than use some NPM powered compress - or whatever - you could just tell it to use Sass. But instead of running it through Sass once with a compressed option, it ran it through Sass. Then it ran it through Sass again to compress it, which was awkward because you'd think Sass would just leave it alone, right? CSS is valid Sass or whatever.
But the problem is, your little fancy function that turned HSL into just leave it alone, now Sass would try to process it again and it was failing.
Stephen: Yeah.
Chris: That was a tricky sucker to figure out.
Stephen: Yeah, and it was only on our deploy step. Testing everything locally, it was all working great. Then I tried to get this out [laughter] and everything is failing. It was very difficult to track down but, yeah, we figured out that there is this second run-through happening.
Of course, at that point, any of our custom Sass kind of stuff had been stripped out, and it was just regular old CSS that now Sass is trying to handle the HSL stuff in its own way again because it's ancient Ruby Sass, and that did not go well, so the fix for that--
Chris: It was nice, though. It was a nice change because by just telling it not to compress our CSS at all--
Stephen: Yeah.
Chris: --makes our build process a little bit faster. I'd love to know what the numbers are on that. But anyway, it must be because it's doing less work. Then we were just like, "Screw it. We'll just have Cloudflare compress it," which I've been doing that for ages on other sites and it does a perfectly fine job. Just let it do what it does.
Stephen: Yeah. It's a little easier on our server to just not have to compress that.
Chris: I think so. Pretty cool. That was a way around it. Once we're Dart Sass everywhere, we'll be able to simplify it even more - a little bit. There's that.
Then just real quick, we'll end with this idea of when we're doing buttons. You kind of discovered this. It turns out this is a major gotcha with custom properties at all is that if you have a custom property that references another custom property, that's kind of like a one-time operation in CSS. Unless you redeclare it where you're using it, you kind of need to declare both of those properties at that level.
Stephen: Yeah.
Chris: You know what I mean? This is really hard to mouth blog, so I'm sorry about that. It's one of the reasons that we didn't break all the colors into their HSL parts because I think we would have run into this exact same problem. You can't just be like, "Oh, on button.varation3, just override --CP-color1s for saturation."
Stephen: Right.
Chris: It wouldn't have done anything because you have to redeclare that kind of combiner [laughter] custom property.
Stephen: Right.
Chris: On the button as well, and that's just untenably weird.
Stephen: Yeah. The CSS variables, like where they're declared, it's kind of scoped there. If you're referencing another CSS variable in a CSS variable, it's locked into that level. You can override it if you're targeting that same selector or maybe even the same specificity, but it's really weird.
We're getting around that with the way that we do the HSL values because we're declaring those on the root as well as the wrapper version of that that's ready to use. That works okay, but if we were trying to override that on body or down the line for just header or something, that wouldn't work.
Chris: Something about my brain, it seems like it will work.
Stephen: Right.
Chris: You know? That's why it's a gotcha because you're like, "Whatever. I'm overriding a custom property and it's referencing that custom property. Why aren't you working?"
Stephen: Yeah.
Chris: I don't know if CSS will ever change that or if that's highly intentional that it doesn't work like that, but it certainly is a brain twister.
Stephen: Yeah, it'd be nice to have a little function wrapper or something that would allow you to reference those values in the current scope.
Chris: Yeah. All right. Well, we finished this whole project and now CodePen just looks exactly how it did before.
Stephen: You're welcome.
Chris: It's very modernized and there's no ambiguity. We do have a couple of leftover things. I think those Sass colors are even still in our code base.
Stephen: They are. Yeah.
Chris: It was definitely like, "Gawd! Can we please kill these things?" because then it will feel very done. But there are just a couple of places where they're still needed. But I notice you named the file something like colors_do_not_use_this. [Laughter]
Stephen: [Laughter]
Stephen: Yeah, so one of the niceties of this was stripping out everywhere that we're using @import-colors.css.
Chris: Yeah. You don't need to do that anymore.
Stephen: We don't need that anymore. There's only two leftover areas that still need to reference those variables. Those variables are kind of handy to use in the theming setup, like setting up all of these variables. We can reference those older Sass variable colors, at least for a time, to allow us to transition our mental process a little easier.
Chris: Yeah. All right, folks. Custom properties, they're super cool.
Stephen: Use them.
Chris: Not just for colors, but they're great for colors. See ya.
[Radio channel adjustment]