999: Writing Maintainable CSS

Scott and Wes break down what makes CSS truly manageable—from preventing style leaks and embracing fluid layouts to choosing the right methodology, whether that’s utility CSS, component-scoped styles, or CSS modules. They also dive into practical tips like leveraging CSS variables, layers, scoping, and tooling to keep your stylesheets clean and scalable. Show Notes 00:00 Welcome to Syntax! 01:31 Understanding CSS Manageability 01:44 This CSS doesn’t leak to other parts of website. 03:41 This CSS is easy to maintain. 05:54 This CSS is reusable. 06:10 Global Solutions Instead of Local Solutions. 07:12 Flexibility and Adaptability in CSS 09:36 Fluid Typography and Responsive Design fluid-type 12:09 Variables and Consistency in CSS 13:40 Brought to you by Sentry.io. 14:14 Values vs Variables. Project Wallace. 18:19 Choosing the Right CSS Methodology 18:48 Utility CSS and Atomic CSS 22:35 Exploring StyleX and Other Approaches Syntax Ep 650. 25:14 Panda CSS. 25:37 Component Scoped CSS: A Preferred Approach 29:08 The Evolution of CSS Modules 34:03 Global CSS: Best Practices Josh Comeau’s CSS Reset. Scott’s Graffiti UI. 38:22 Harnessing CSS Variables 41:33 Understanding CSS Layers 43:52 The Power of CSS Scoping 46:16 Enforcing CSS Standards with Tools Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Wes Bos?

  Welcome to Sendax. Today, we're talking about writing maintainable CSS. How to structure your project, how to write CSS so that you don't end up with just a dumpster fire of CSS that's impossible. Your website starts to rot over time randomly. You find like the one thing that you can tell when a website has rotting CSS is you see like a Times New Roman sneak out or like a weird font that doesn't belong there. You know, it's just like, oh, man, you know that this is this is probably a mess inside. So how do you write maintainable, manageable CSS? What are some good approaches to do? What are

• 0:39Wes Bos?

  some methods as well as what about Tailwind Utility Frameworks, Atomic CSS, Stilex Component, Scope CSS? There's different approaches to do. We're going to talk through those as well as maybe some tools to enforce that yourself. My name is Wes Boss. I'm a developer from Canada. With me is Mr. Scott Tolinski, absolute slop master of all CSS, knows what he's talking about here.

• 1:05Scott Tolinski?

  Yes. Yes, I have been there. I have been there, done that. Man, Wes, I, speaking of non-slop, I went to dance yesterday and it was my first dance practice in my 40s. And boy, oh, does, uh, does that hit different. Why does that hit different? That's, that's for sure. I'm feeling it. Oh.

• 1:28Wes Bos?

  Oh, man, that's great. All right, let's get on into it. First of all, let's talk about what makes CSS manageable or unmanageable. And then we're going to go into the different methods and approaches that you can use as well as some tips as to how to write good CSS. So first of all, like, like what causes CSS to be a mess or unmanageable, right? Very high level CSS does not leak into other parts of the website. This is a very clear one is if you are writing some CSS and those styles are accidentally leaked to other parts of the website, or those styles are so broad that you would not be able to take part of a website away, where we'll use the word component in this, you know, you should be

• 2:13Wes Bos?

  able to take a component out of your website and render it on a white page and it should still look mostly the same or entirely the same, right? And if that component only looks that way inside of a specific part of your website, you have a bit of a rat's nest of CSS.

• 2:29Scott Tolinski?

  Yeah, man. Which is something that I feel like, you know, with the current landscape of how AI likes to write CSS and things like that, it's definitely a code smell that I think a lot of people will have in their projects.

• 2:45Wes Bos?

  Yeah. Yeah, I feel like it's less of an issue these days as people, most people are using something in their CSS instead of just having one big style CSS file and dump a whole bunch of rules in there. I feel like it's a little bit more maintainable. Most people have some sort of idea of components and hopefully some way to to manage that CSS, but even with those things in place, it can still get out of hand.

• 3:12Scott Tolinski?

  Yeah, and I think a bigger concern these days is having every single component as a tight unit that if you do adjust anything as a global anything, then that tight unit will remain in the old style of things, right? Is like a lack of the cascade is a huge problem.

• 3:37Wes Bos?

  The tight units are a problem.

• 3:39Scott Tolinski?

  Tight units.

• 3:41Wes Bos?

  Another thing, what makes me CSS maintainable is, is it easy to maintain? Updates, edits, this includes being able to find the actual thing because there are certainly lots of CSS approaches out there that are so stringent and so hard to use that people end up not being able to do what they want, right? And you're baked into, this is kind of the thing with like design systems as well. With larger companies, you need, the larger the company, the more places that it touches, you need a more strict design system so that you can enforce these things across the thing. And that always comes with a trade off of like, I'm not actually able to, like,

• 4:23Wes Bos?

  a good design system will let you do whatever it is that you want, but there certainly is this other spot where if it's too stringent, you're not able to actually implement the design that you're looking for. And then that causes people to sort of step outside and then just quickly do a little hack here and there and then voila, a year later, you have quite a bit of rot in your codebase.

• 4:45Scott Tolinski?

  Yeah, yeah, totally. And that's a problem that I have. I'm really good at designing a system, but less good at designing. Individual, unique elements. So for me, my stuff can feel like it's soulless in a system, but I, I, I am afraid, I'm afraid, if I are bad of, of, of doing a

• 5:08Wes Bos?

  I think we're the unique thing of this because you are, you're the, the system guy. And I love a good system, but I also sometimes find it like, I just want to set a fricking font size on this thing. And it's, the, the font size is this like 92 line clamp function where I can't figure it out. Um, and, and I think like those are fine for 90% of use cases, but you should still have a maintainable way to sort of break outside, even on the syntax website. I think we ended up, we have, have that, those font sizes for most things, but I added a couple of utility classes for simply just changing the font size to something that was outside of that clamp function.

• 5:52Scott Tolinski?

  Yeah, yeah, totally. For good CSS to be maintainable, it has to be reusable. And this has gotten different now with components, scoping things to components, because many times that unit of what is reusable can just be in a component rather than just a class or this or that. But CSS should not be a one-off solution. I actually have this kind of same thing listed as global solutions, uh, instead of local solutions. And when I say global, I don't mean in a global dot CSS file that gets imported everywhere. What I mean is that like the table CSS shouldn't live in the page admin table component. It should live in a more generic

• 6:36Scott Tolinski?

  reusable component and/or class, uh, that is then able to be then used anytime you have a table.

• 6:44Wes Bos?

  Yes. Yes, exactly. And what that ends up looking like is you, you find yourself re-implementing a lot of the base elements in, in HTML, right? You, you find yourself re-implementing a heading component. Uh, obviously a table is a very common one, you know, like maybe a, a section, because like those are your base cases that you can then pass in arguments or overwrite values with, with variables.

• 7:12Wes Bos?

  Now, here's one thought that I have with a lot of CSS that people have is that your CSS needs to embrace the flex. And what I mean by this is writing good CSS means that your CSS will adapt to breakpoints, container sizes, different types of content wrapping without too much extra code. Often what I'll see is people are simply just re-implementing the CSS for every single breakpoint, or they have to duplicate their HTML because it's so different from one to another. Where writing media queries and container queries and all that stuff, that is fine, but your media queries should not have to like write every single

• 7:54Wes Bos?

  selector and re-implement absolutely everything. Is that they should be flexible enough that when things change, when a component is in a space that has more width or height, or when a breakpoint is much smaller than larger, that the contents will sort of just flex to them. You don't even have to write media queries. Or if you are writing media queries, you are writing container queries. A lot of that work is simply just updating variables. All right, at this breakpoint, I'm going down to three columns and I'm changing the font size to be something slightly different, right? Rather than having to just like write every single selector again, because I hate debugging that CSS where it's just like, oh,

• 8:35Wes Bos?

  I want to edit this thing. Now I have to go through 11 different media queries, find all of the selectors. I prefer nesting my media queries inside of my CSS versus the other way around. But that's, that's one thing, especially AI does that all the time, and I hate it.

• 8:53Scott Tolinski?

  Yeah. Yeah, I think this is one that, man, it's hard to wrap your head around these types of things sometimes because it's so easy to read a media query where it's like, at this, it's this, at this, it's this, at this, it's this, rather than building more flexible systems that adapt.

• 9:13Wes Bos?

  The things that you would use there are what? Like min-max, auto-fit, autofill, and grid, flex-flap, clamp, that's a really good one.

• 9:23Wes Bos?

  There's quite a few little things where if you can just learn how these all work, then you might not even have to write any media queries.

• 9:30Scott Tolinski?

  Yeah, I grid, man. Grid has just such an amazing capacity to adapt to its container.

• 9:36Wes Bos?

  And can you explain your clamp font sizing hack where like you don't even have to? Like, I know I was razzing you earlier, but it actually makes a lot of sense because there are very few use cases where you need to make the font smaller on mobile when you use this approach.

• 9:52Scott Tolinski?

  Yeah, so this is my, this is a fluid hyphen type dot tolin dot ski. This is a fluid type generator that I built that everything is based off of math ratios and clamp. And if we look at this, you have this massive clamp function where you have a 16 pixel based, rem based clamping function that basically says, here's what the font size is preferred to be at any given point. And then it's going to clamp down to a minimum for mobile. In this case, it's 14 pixels for mobile at the viewport size of 400 and

• 10:36Scott Tolinski?

  the maximum of 20 pixels at desktop size. And that's for the base level font, like your paragraph font. Then at any given point, it's going to, if it can be its maximum based on the viewport size, in this case, it will be its maximum. And at the minimum viewport size, it will be its minimum. But in between there, what it does is it picks the point in the middle of all of that, making it just totally fluid. And it's funny, I actually have this be a container query based as well, too. So you can have this be container query based or viewport based, based on how you choose. I have it based on a toggle. And then the way I also have it, because this is all just the base level font size, you can choose

• 11:21Scott Tolinski?

  the font scale as well. So like, what is that ratio between the two of these? Is that ratio is bigger than your font sizes at the larger end of the spectrum will be massive? And if it's smaller, then that ratio ends up becoming smaller. And then you can tweak the baseline, like if you want your smallest font size to be 16, you can have that be 16 instead of whatever. So check out this fluid type calculator, because at the end of the day, what it spits out for you is just, man, a handful of lines of CSS that calculates all of this fluid type, uh, fluid font based on CSS variables. This is what I tend to use for all of my font sizing. It, it can though, Wes, like as you've mentioned, it can become a PIA if you just want to stink

• 12:04Scott Tolinski?

  at font size. But if you're like, oh, I just want a system that looks nice, I like this quite a bit.

• 12:09Wes Bos?

  And like, it's just mobile friendly already. You don't even have to think about it, right? Like that, you don't have to slap any media queries in there. It just simply goes.

• 12:17Scott Tolinski?

  And the scale is all relative, so it always looks like the same. Yeah.

• 12:21Wes Bos?

  Yeah. I saw a tweet the other day, someone said, why are we setting font size based on like pixels or REMS or whatever? Why is it not, why is everything just not line height? Cause you have this like new value in CSS, like LH, right? Um, and we also have like CH and EX, which is the size of an X and the size of a, what's CH? Is it a C?

• 12:45Scott Tolinski?

  Oh, character height?

• 12:46Wes Bos?

  Character height. Yeah. Yeah, exactly. But like line height, sizing everything based on line height. And that way you get like a nice rhythm vertically. And I was like, I think that makes sense. I don't know why I've never tried that.

• 12:58Scott Tolinski?

  There used to be, focus who, people who don't know, there used to be this thing called SAS. And there, when SAS came out, there was this thing called Compass, which was like a toolkit for SAS. And in that toolkit was vertical rhythm, which took line height and distributed the font size and put it all as if you would establish a vertical rhythm for your entire document, then it would make sure your text always fell into that vertical rhythm. I like that.

• 13:25Wes Bos?

  And you could, and if you were like doing like icons or something, you could snap them to the closest. Vertical rhythm with clamp, right? Makes a lot of sense. I guess folks want to do that as well. But yeah, kind of a neat approach. I'm going to try it on my next project.

• 13:39Scott Tolinski?

  Yeah. And if you want to see all of the errors in your application, you'll want to check out Sentry at sentry.io/syntax. You don't want a production application out there that, well, you have no visibility into in case something is blowing up and you might not even know it. So head on over to sentry.io/syntax. Again, we've been using this tool for a long time and it totally rules. All right.

• 14:04Wes Bos?

  All right. So that, I think like anything else that makes your CSS unmanageable or unmaintainable?

• 14:10Scott Tolinski?

  Um, things that make my CSS unmaintainable. I think one of the bigger things that we've talked a little bit about being systems and reusable and stuff.

• 14:21Wes Bos?

  Yeah.

• 14:22Scott Tolinski?

  But it's using values instead of variables. I know we'll talk about using variables in a bit here, but there are some things that just straight up should be variables in my mind all the time. Fonts, font sizes, colors, shadows, those types of things. When you define them one-off, especially with AI agents, you can have, next thing you know, 40 different shadow types in your site. And that's like a guaranteed way to make things not only unmaintainable, but also non-cohesive in the way that it looks. So again, we're talking, I'm a system guy, right? So I really love variables for everything.

• 15:05Scott Tolinski?

  And I forbid them, certain properties to have individual values set on them that aren't a variable.

• 15:12Wes Bos?

  Honestly, it's a great approach because as soon as you introduce like eight different types of like gray borders into your website, then

• 15:22Wes Bos?

  And you want to update it like you want to add dark mode, you know, or you want to re-style your thing. You're just hunting through the website for all these different use cases. One kind of cool site is if you go on projectwallace.com and put your site in, they will show you all of the colors that are used on a website. And it's kind of funny to like pipe in a, I think you go to, yeah, you go to the design tokens and it'll show you all the colors that are used on a website. If you type in several different websites, you're going to hit upon some sites that like, oh, I see that they've used the blue, but the blue has deviated because somebody used a color picker here, someone used RGB here versus somebody else used like HSL and it's slightly different. And then it's just,

• 16:07Wes Bos?

  it's just deviated over time. And I'm very happy looking at syntax out of them where there is one yellow, two yellows.

• 16:18Scott Tolinski?

  There's a variable system for a bunch of different yellows. We just don't use them.

• 16:21Wes Bos?

  Yeah. Oh, yeah. But yeah, I mean, like the actual used yellow that we use for syntax is the same across the board. And that way, we actually have them in the index site. We can just change one variable and the whole site will update.

• 16:34Scott Tolinski?

  Yeah. And in that same regard about changing one variable and having the site update, I think one thing that is people using non-relative things, like we have, especially with colors nowadays, we have relative colors. Colors can be derived from other colors.

• 16:51Wes Bos?

  Yeah.

• 16:51Scott Tolinski?

  Those types of systems, I think, often end up being the most maintainable because even if you're using an opacity, right? If you have like a transparent blue, people will define the blue and then they'll define the parent blue instead of having the blue and then deriving the transparent blue from that blue, right?

• 17:12Wes Bos?

  Yeah.

• 17:12Scott Tolinski?

  You can get things out of sync that way.

• 17:14Wes Bos?

  And if, let's say you have like a, like a purple and then you want like a slightly brighter purple to put as like a border on a card. And then you want a slightly darker one for like a box shadow. Are you then sticking those? In variables as well?

• 17:31Scott Tolinski?

  I am.

• 17:32Wes Bos?

  Or are you supposed to just compute it? Okay, good. You're not just... That's another thing AI loves to do is just compute them in place. Because I had this rule.

• 17:38Scott Tolinski?

  Yeah.

• 17:39Wes Bos?

  Do not use any colors that are not in variables. And then what it did is like, okay, it just took the variable and then used relative colors. I'm using it, but I'm just computing what I want from that.

• 17:52Scott Tolinski?

  Yeah, yeah, right, yeah. I have, we talked about this in the last episode, Wes, about non-deterministic tools or deterministic tools. Stylent blocks me from that. Yeah, so it says.

• 18:04Wes Bos?

  That's good.

• 18:05Scott Tolinski?

  Specifically, if it's a color value and it's not a custom property as the value, then error out. Yeah.

• 18:12Wes Bos?

  Yeah, that's, that's good. You need to be very stringent with those types of things. Otherwise, it kind of gets away from you. Let's talk about methods and approaches, right? Like, when, what is not important is which system you pick. What is important is that you pick a system and you stick with it as close as you can. Because if you have a system and then you maybe use a different system here and then you mix and match, and then all of a sudden, they just start to deviate from each other. That's where you can, can run into trouble. So, let's, let's run through some of the more common approaches out there. So, first one here is utility CSS. Most likely, everybody is using Tailwind for this type of thing,

• 18:54Wes Bos?

  where you have lots of classes that are associated with the different properties, different padding values. They're scoped a little bit smaller, meaning that you don't have access to the full gamut of, of values, which is often good, because then you have like six different kinds of shadows, or four different kinds of spacing. But then, of course, you can use computed properties to actually inject your own version in there as well. And quite honestly, when I use Tailwind myself, I find myself using the computed values quite a bit, because I don't, I find myself wanting like a little slice in between one of these values, or setting up my own utility class, extending it a little bit.

• 19:34Wes Bos?

  With a utility CSS approach, the reusable reusability factor moves from like selectors to like components that are reusable. Because like, if you look at it, there's bazillion classes on on an element. And then you find yourself going, oh, well, like now I have two things on this page that need to look the same way. Am I just copy pasting it? Or sometimes people put the classes in like a variable and then they use that that's a okay way to do it. But generally, the approach to this is instead of creating a selector somewhere with your CSS, you're simply just making a component that has all of those

• 20:16Wes Bos?

  reusable components on. It's not my favorite approach. I certainly use it in, I don't know, I have three or four websites that use it. But lots of people absolutely love this approach.

• 20:27Scott Tolinski?

  Yeah, I think people like it because it solves scoping for them because they're using component flows, they're scoping their CSS, they're not having to worry about classes and leaking and those types of things. They like it because there's a system. But again, yeah, I find it's just like a shorthand, like a CSS shorthand.

• 20:44Wes Bos?

  Yeah.

• 20:45Scott Tolinski?

  And to me personally, yeah, that's why I don't I don't personally use it. But I get why people like it. It does. It makes it easier to have a system in place. You have atomic CSS as being a separate thing in here as to utility CSS. I've always seen those as the same thing, but I don't have any strong feelings there. Do you see them as being different?

• 21:04Wes Bos?

  Honestly, I don't. I don't either. Atomic CSS is the same idea, right? You have these small classes that simply do one thing. It changes the border color, it changes the width of the element. Uno CSS is very big in this regard. And it differs from Tailwind in that Tailwind is somewhat opinionated with with what you can do with it, which is good, because then it stops people from making a mess with with everything, right? Like it scopes down what you can change on your on your selectors. With with atomic CSS, you can essentially build your own Tailwind. So if you don't like the way that Tailwind does something, or if you don't like the fact that it doesn't have the ability to

• 21:49Wes Bos?

  do a certain pixel value, you can you can go and build your own little thing with Uno CSS. And it's pretty cool. It uses Lightning CSS. It's from Ant Fu, who's the creator of absolutely everything. And

• 22:04Wes Bos?

  Yeah, it's pretty cool. I'm looking at this and thinking, hmm, that'd be kind of cool to hmm, build my own, but I don't think I ever will. I prefer, we'll get to what I prefer, but I like a utility CSS as a sprinkle on top for common use cases for things that I want to do, you know, changing the font size, maybe margins here or there, but I don't like it for absolutely everything. I'd rather have a selector that I can reuse throughout my, my code base.

• 22:35Scott Tolinski?

  Yeah. Next, we have style X, which this one, this is, is this a React specific thing?

• 22:43Wes Bos?

  No, it is from Facebook, though.

• 22:46Scott Tolinski?

  Okay.

• 22:47Wes Bos?

  It's like styled JSX, I guess. We did a show on it quite a while ago called Why Is Facebook's CSS Such A Mess? Because if you inspect element on any Facebook property, you're going to see just generated class names. And if you look at those generated class names, you'll see that every single one of those generated class names, it'll be like x4h2f, and that will be related to like border bottom red. And that's not how it's actually authored. That is simply, what style X does is it takes in kind of like your traditional CSS where you, you write like a, you don't write a class, you write

• 23:31Wes Bos?

  it inline in a JavaScript object. And then you, you apply all the styles that you want, you know, you can apply font size and border and padding and all of that stuff. And then it will take all of those for your, from your entire project and go, oh, they used margin 40 pixel in 19 times throughout this entire website. I'm going to replace that with one single class called BFR LOL 69. And then, so if, if you look at Facebook's source code, people are like, who would write code this way? They're not. They're not authoring that at all. They're simply just writing the CSS inline as JavaScript objects on their components. And then they have a, a build step that sort of takes that

• 24:14Wes Bos?

  out. And the benefit to that is that you never write the same line of CSS twice. You never ship the same line of CSS twice. You could use margin 40 pixels 1,000 times throughout your website. You're only ever shipping one selector and one property value for that.

• 24:31Scott Tolinski?

  Yeah, yeah, I got, I gotta say, there's, there's a large parts of Stylx syntax that I just can't get behind.

• 24:38Wes Bos?

  I hate writing CSS.

• 24:41Scott Tolinski?

  The media queries syntax in this, because yeah, because yeah, you're writing it as a JavaScript object, which already sucks because.

• 24:48Wes Bos?

  No, thanks.

• 24:48Scott Tolinski?

  No, thanks. But then you look at the, the media query syntax and it is just, what are we doing here? Uh, so yeah, it's bizarre. Um, it's not for me. I'll just say.

• 25:02Wes Bos?

  No, and you think about like, container queries and now we have style queries and

• 25:08Scott Tolinski?

  Right.

• 25:09Wes Bos?

  like nesting and all that. And it's just like, this is not the right way to build it. One kind of interesting spot is if you are interested in this sort of area, Panda CSS has kind of the same idea, but they have multiple ways to write it. So you can write it in CSS modules or you can write it in line. Um, and then again, they just parse it all out for you. So Panda CSS is a, is a really nice approach. I quite like this one myself.

• 25:38Scott Tolinski?

  Yeah, yeah. Next is component scoped CSS. This is how I prefer to work now. Uh, a Vue JS has component scoped CSS. Svelte has component scoped CSS. Back when I used CSS and JS like styled components, I wrote it in a way that was just scoped to my component. Uh, I, I adore this way of working because you can target elements without having class names and things like that. You can, uh, your CSS becomes scoped to the component that you're authoring the, the CSS in. That way you can have a layer of base CSS that's global. You can have local CSS that doesn't leak anywhere.

• 26:22Scott Tolinski?

  You don't have to come up with a thousand different classes for naming things.

• 26:26Wes Bos?

  That's the best.

• 26:27Scott Tolinski?

  It's the best and it's only going to get better because we're getting native, uh, scoping in CSS. Therefore you can, uh, not rely on your JavaScript framework to do that scoping. You can use the scope and then scope to a class or anything like that and then have that.

• 26:45Wes Bos?

  A div. Yes. This honestly, this is the one thing that I miss from when I'm not doing a Svelte project. And it's like, I just want to put a style tag in the same file as my, my component. And, and that's why people like Tailwind so much as well is because. I go to the component that I'm working on and what it looks like, how it's styled, and often the actual like logic behind how it works is often in the same file. And it's it's beautiful. I absolutely love it. And like, you can simply just write very bare selector, like div or strong, and you don't have to like come up with a crazy name for it. And I love that approach to this. The one thing I don't like about this component,

• 27:29Wes Bos?

  Scope CSS, is when you have a component and you have some CSS in there, and then you nest a component inside that's maybe two or three levels down. And you say, okay, when like, let's say, for example, I have like a tag, and it's inside of like a show card. And I say, ah, I want the tag to be red in this case. There's no way to like, select the child component without having to use the weird like, colon global thing, or you'd have to like, pass down a prop from the parent to the child. And then then your prop drilling, which which I don't like as well. So sometimes I just want to simply just say, yeah, when there's a child that has,

• 28:14Wes Bos?

  ideally by the component name, or maybe by the class name, that you could have. That's what that is something that CSS modules does support, which is really cool.

• 28:24Scott Tolinski?

  Yeah, yeah, it's a, it's, I agree on all those cases. The nice thing about this flow in general is that you get access to all of CSS in an ergonomic syntax, where like, if you're using something like StyleLand, or even Tailwind, you have to have them, I mean, you can obviously write normal CSS when you write Tailwind, but like, if you're going all in on their classes, you have to learn their their version of doing things, whether that is container queries or whatever, CSS has just got it available from day one. If the moment it's available in the browsers, you got it.

• 28:57Wes Bos?

  It's available to you. And any tools that are therefore working with CSS generally work immediately with this because it's just CSS, right? CSS modules, it's been one that's been around forever. The way that this works is that you write your CSS in a separate CSS file. And then you import the classes from that CSS file in your JavaScript. So maybe I'll have a footer and then I will import the footer styles from that. And then what that turns into in your bundling step is like a class name that's associated with those scoped styles. And then you can apply that class to your footer.

• 29:41Wes Bos?

  And then if you have other elements, the one thing I don't like about it is if you have other elements, like let's say you have like a footer header, then you have to also import the footer header styles from that one. You can't just simply just like use nesting. I get it because you can get in trouble with writing very deeply nested CSS and they much prefer you to say, no, let me just write this top level scoped CSS that is not dependent on any of its parents. But sometimes I just want to select the H3 inside of my footer without having to do all these jumping around, which is why I like the Svelte or the scoped CSS approach so much more. I use CSS modules on my own personal website. I moved it over, I don't know, it'll be a year or two ago.

• 30:25Wes Bos?

  And I've been, I've been like a 91% happy with it. And I think the only thing I don't like about it is that I have separate files and I'd much rather have the CSS and the component in the same file.

• 30:38Scott Tolinski?

  Yeah, it's one of the reasons why I like the single file component thing, but then that has its own trade offs, which, yeah.

• 30:44Wes Bos?

  Yeah, like, like, let's say you want two different components, but you want to share the CSS. Like, what do you do in that case? Can you import external CSS in Svelte?

• 30:52Scott Tolinski?

  Or? Yeah, yeah, yeah. You just import an external file, no problem.

• 30:56Wes Bos?

  Yeah. And then it scopes it to that, that value there?

• 31:00Scott Tolinski?

  I don't know if it scopes it. I don't know if it scopes it. I think it's just a beat.

• 31:03Wes Bos?

  It's just global CSS.

• 31:04Scott Tolinski?

  Yeah, that's actually.

• 31:05Wes Bos?

  Yeah, see, that's that sucks because I'm like, I want this scope. But then so what you have to do then is you have to make a component that is reusable. And then that component needs to be extended.

• 31:16Scott Tolinski?

  Yes.

• 31:17Wes Bos?

  On the two different use cases and then it's it's a problem. I don't find that I hit that that often, though. Do you?

• 31:23Scott Tolinski?

  No, no, I don't.

• 31:23Wes Bos?

  No, no, it's very. What else is there? CSS modules we talked about. There's so many other methods, CSS and JS, which is very popular. Panda is technically CSS in JS, but it's not a runtime thing, which is is great. That's a style components was a runtime thing, which at the time it was great because you could use your JavaScript values inside your CSS. But then you have all this rendering overhead. So Panda is simply a build time thing, meaning that it will. You write them in your JavaScript, but it will strip out those styles and and you don't actually have to. They're not calculated every single time your component re renders.

• 32:01Scott Tolinski?

  Right.

• 32:01Wes Bos?

  BEM was really popular, SMACs, object oriented CSS. These were all approaches to build things that were scoped, that were composable. You know, like if you have a button and then you want a button that is big and a button that is red or a button that is a warning. You can compose these things together to to build what you want.

• 32:24Scott Tolinski?

  BEM was really necessary. Yeah, BEM was really necessary because we didn't have components. You didn't have scoping in that kind of way. And it was block element modifier. It was a system for devising names for things. Again, we had we had to name things in this sort of way, in a way that was like a such structured system. And it felt verbose to me. I did use BEM quite a bit in the past, but I haven't reached for BEM in a really long time.

• 32:51Wes Bos?

  Me neither. And for some reason, my AI always tries to get me to use it. And I was like, no, like, I don't, I don't need this anymore, you know? But like, do you remember what the BEM methodology was? Like, if I were to ask you to write a BEM selector right now?

• 33:06Scott Tolinski?

  Ah, I remember there was hyphens and underscores.

• 33:09Wes Bos?

  Yeah.

• 33:10Scott Tolinski?

  Block is like a component, right? Or block is a collection of components, maybe?

• 33:14Wes Bos?

  Yeah, block would be like a component, like a card or a footer or something like that.

• 33:19Scott Tolinski?

  And then the element is the individual element and then the modifier would be like an is active. But what I don't know is like, what's the underscores and what's the hyphens? It's been a while.

• 33:29Wes Bos?

  Yeah, it would be like, like footer is your block. Underscore, underscore, heading would be like a footer heading. And then a modifier would be like invalid or on sale. And that was the dash, dash value there. And, and people love that because in SaaS, you could nest your selectors. And they would just chain them into one big one. Um, and you can't do that in, in regular CSS nesting, which you also probably shouldn't do that because it's not statically analyzable.

• 33:57Scott Tolinski?

  I used the life out of that. Yes, I did.

• 33:59Wes Bos?

  That was, yeah. Ben was the greatest, big fan, but no longer. Tips, let's talk about writing, writing CSS and good tips. A good global CSS. We talk so much about like scope your styles, make them tight, not repeatable. But then a lot of people who do that, they find themselves writing the same CSS over and over again. Where in, in reality, you should have a good base that includes some sort of normalize or reset. I really liked the Josh Komu reset. I've been finding myself, I just copy paste that one every single time I start a project. Um, and then that global base will have all of your, your defaults for your typography.

• 34:41Wes Bos?

  Has a lot of your colors and your variables that are being used. Um, often you should set your color scheme in there if you support light or dark or both. Uh, what other types of stuff is, is that kind of globally done?

• 34:55Scott Tolinski?

  Yeah, for me, I, I actually Wes, I lean pretty hard on global CSS. So, um, I've talked about this a number of times on our show. I lean so hard into, to global CSS that I wrote my own, uh, UI library graffiti, which has a lot of global CSS. So I do all my typography, but I also like, at what point is your variable system? Your variable system feels like that is global CSS to me.

• 35:22Scott Tolinski?

  Because that's usually included everywhere.

• 35:25Wes Bos?

  I think so. If I'm defining a variable, I either define it globally because it needs to be throughout the entire thing and those are generally like font sizes, colors, et cetera. Or you do it at a component level. Or you do, you do your component variables globally as defaults and then your components can simply just overwrite those variables.

• 35:44Scott Tolinski?

  If you're asking me, a, a good global CSS should mean that with just elements and no classes, you should be able to have decent looking forms, like your form should look like, all of your form elements should look good. All of the base level elements should match your theme. And if you were to just write HTML, no classes, it should look good. Now, to me, that's what a base level CSS should do. And then everything else on top of there is like icing on the component cake there.

• 36:21Wes Bos?

  A lot of people say the opposite, where your CSS should be simply just stripped out. That's what like the tailwind preflight does is it, it goes even further in than normalize and it takes off all the styles. So you put an h3 in there, you can't tell the difference from an h3 to a paragraph tag. I think I agree with you as well. But I certainly do hit cases where I'm just like, ah, now I have to undo all of the stuff that you added to my table because I don't want that. And it can be done though with, um, one used property in CSS people don't know a lot about is the unset all. And that will simply just take all the properties that were applied to it

• 37:04Wes Bos?

  and, and unset them and bring you back to the base. It's a little bit of a pain in the butt every now and then because I find that that overrides some of my specificity. But it's fine.

• 37:15Scott Tolinski?

  I would, I will say when I say it looks good, I mean, it looks like if you were having like a blank page, it shouldn't have a lot of character. It should look. Good, good within your system because I think one of the things that people fall into the trap of is is really finally having to tune every single component just to have it look good rather than having a system that looks good and using the tuning to tune. So that's just my, but I again, that yeah, that's definitely like a preference thing.

• 37:44Wes Bos?

  I agree, actually, because when I used to do like WordPress themes, I would, at one point I was stripping all the styles and then I would just build them all up again. And then what would happen is the, the client would like go in the WYSIWYG and add some content like a, like a UL nested inside of an OL or like they would do some case where I didn't account for that. And, and then I was, oh, I didn't, I didn't account for that type of content, right? Essentially, if you're stripping out all of the browser styles, you better like make sure you put them all back. Otherwise you're going to hit some weird use case, some markup that you didn't account for and it's going to look weird.

• 38:21Scott Tolinski?

  Yeah, yeah. Variables, yes. I, man, variables are great in modern CSS. And for people who don't know why, variables are so much better in modern CSS than what we had in SASS because in SASS, it was a build time thing. In CSS, these things are updated live. You can think about your props, right? You change your prop, your component updates. So with CSS variables, you change your variable, it updates. You change it at its parent level, it nests down like the cascade, it cascades down. There are so many wonderful things about variables. They can be used to then generate other things like colors. They can be used

• 39:01Scott Tolinski?

  in calc to be able to have relative systems of spacing and stuff like that. I define all of my variables at a root level using the colon root pseudo selector and then override where needed. I think an underused feature of CSS variables is the @property definition. @property allows you to get a little bit more control over some of your variables. This is like defining a type for it. People often say that's great.

• 39:35Wes Bos?

  So it can be animated, right?

• 39:36Scott Tolinski?

  Animated and yeah, because now you know exactly what type it is. It's not just like a string. But I think one of the things that people don't use very much is the inherits value in add property. Inherit can be true or false, and that means that if like, for instance, if I'm building, I use this in graffiti. If you have a gap, if you have a layout class and you have two elements inside of there, and you set the gap on the parent, and then you have another layout that's nested inside of that, without the inherits on here, inherits false, this gap would then cascade down to the other gap. So you set a gap here, that gap is now big on any children, and any children, children, and any children, children.

• 40:21Scott Tolinski?

  And if you have inherit set to false, it doesn't cascade down. Therefore, it gives you the ability to still use variables to control essentially properties or props on, on elements or components without having to worry about that cascading downwards effect, which again, I think, underutilized.

• 40:39Wes Bos?

  So true. Like, the gap one is a really good example because if you have like a layout, and then your entire site layout, oh, I want to change the gap on the layout, right, to 10 pixels. If, without that, you just change the gap for everything else. And then you have to go back and set it back on all the other ones. So, and also for things like, like in CSS, there's many properties like, like top right, bottom left, what are the things like padding, margin, borders? These things don't necessarily inherit. When you set a border on an element, all of its childrens don't automatically inherit that value, right?

• 41:15Scott Tolinski?

  Right.

• 41:16Wes Bos?

  So you want to use this.

• 41:17Scott Tolinski?

  And it allows you to build relative systems without having to worry about like cascading downwards effect. It's great. Yes. I put everything in variables, by the way, folks. I put everything, any type of thing. It's in variables, so.

• 41:31Wes Bos?

  It's all there. Another thing you can use in CSS that is, I think severely underused is CSS layers. What this allows you to do is you can essentially take your CSS and put it into a specific layer. And this may be a reset layer, a defaults layer, an animations layer, and then you can control the order in which the that CSS applied in the cascade. So if you have ever fought with the the wrong CSS being applied over one or the other, it is so much easier to simply just stick them in a layer and explicitly

• 42:11Wes Bos?

  tell the browser, apply them in this order. And Tailwind 4 uses CSS layers as well. So you're starting to see it quite a bit be applied to it. And especially also, if you have like, if you're writing some like customization, right? You may have a base theme, and then you want to like, add a bit of customization to overwrite some of those values, just make another layer, tack that on the end, and you know that that CSS is going to be applied over top of the existing one. You don't have to start fighting with crazy specificity selectors, or like, over, you're like, oh, the dot heading didn't work. Let me just do h2 dot heading. Now that's more specific.

• 42:50Scott Tolinski?

  Yep. Yeah, I think, you know, that's one of those things that people can get really into trouble with, with this is like, the moment they start applying overrides to the specificity tree to gain some sort of control. It's the same classic issue that we've talked about, going back to day one of CSS. If you throw an important on something, it is a sign that there's something wrong. Like, an important is not something you should be using. And likewise, there are times when you start to write some really icky selectors, and it's like, doing this. It's a good sign that like, a layer system, layers could help you out in terms of like, being able to actually gain control over that cascade,

• 43:34Scott Tolinski?

  which I like CSS layers quite a bit.

• 43:36Wes Bos?

  Yeah. I was very sad to find out, though, that important still takes precedence over top of a layer.

• 43:43Scott Tolinski?

  Important is just like, move out of the way. It's me. It's me time.

• 43:47Wes Bos?

  Final boss.

• 43:52Wes Bos?

  Next up, we have scoping. So again, not a lot of people know this, but CSS since December 2025, it's been in Firefox and it's it's been in the rest of the browsers for over a year, almost two years in many of them. We have CSS scoping. And what this allows you to do is much like a layer, you can simply just say at scope and you can give it a selector and then write all of your CSS inside of of that scope. And what it will do is it will simply just scope that to to that specific selector. And that allows you to you can write things like H3 inside of there and you don't have to worry. One cool thing about CSS scoping is like, of course, you can just give it like a selector, which you're probably saying, well, how is that

• 44:36Wes Bos?

  different than just using regular CSS nesting? But one neat thing you can do is if you pop a style tag inside of an element and simply just write at scope and write your CSS inside of there, it will automatically scope that CSS to the closest parent element, meaning that, like, we were just talking with Scott about how I just want to write my CSS in the same file as my my markup. You can do that. You just simply need to you put you need to put a style tag in there and then you need to write at scope. You don't have to provide a selector or anything like that. Just simply at scope and you will then be able to apply all of a CSS

• 45:19Wes Bos?

  to only the elements that exist inside of that element. And then you can also stop the scope by using something called donut scope, meaning that you can you can tell it where the scope starts like a selector, but you can also tell it where the scope stops. And that's really handy is if you're nesting cards, you can say, start the scope from the card, but then stop it at a card, stop it at like the next card and then or stop it at like maybe you have a child element, stop it at dot child. And then that way your cast the cascade stops.

• 45:53Scott Tolinski?

  Yeah, yeah, scoping is one of those things. I think people will start to figure out that really helps them if they pay attention to it because it's great. It's a API we've always wanted. It's native. Yeah. And it's so, it's going to be fun to see frameworks like Vue and Svelte eventually move over to native scoping CSS. It's like one less thing we'll have to support in their own platforms, which is great. We talked a little bit about tooling and enforcement. Styleent is a great project for this because you can set up your rules and those rules can become something that is loud. Hey, you just defined a color with a variable or with a value instead of a variable.

• 46:35Scott Tolinski?

  Go, go make sure you don't do this, but it can also be extremely important when working in teams because we all know that everybody has a different idea of what CSS is. I've worked on teams where I'm just like, and not this team, to be clear, because Wes and CJ write good CSS. But I would just look at the CSS and be like, I want to rewrite all of this. I don't like any of this. But now you don't have to be the bad guy. If you have a tool like this, it can be the bad guy for you. Like, hey,

• 47:05Scott Tolinski?

  go fix this thing that you shouldn't have done. This is bad. Yeah.

• 47:08Wes Bos?

  It gives you the error. Biome also has a CSS linter in it. There's an ESLint plugin. So like whatever your stack is, there likely is already a plugin that will allow you to do these things. They're not all exactly the same. You might, you may find that they leave it to be desired. You want to switch over to one of them. But having a tool like this in your codebase is kind of key to stop you from, from doing crazy stuff, especially when you have like dozens of people writing CSS in there. It's very hard to like enforce that. And nobody likes the guy who comes in, swings into the pull request and then starts giving feedback.

• 47:47Scott Tolinski?

  Yeah, yeah, right. Exactly.

• 47:50Scott Tolinski?

  Um, cool. I don't, I don't have too many other things here. I, I do want to stress relative things are really helpful. And I've said this a number of times in here, but I think oftentimes even in variants and things like that, what we do is we default to going straight to CSS properties. Like one thing that we didn't touch on when we talked about variants and, and variables is that you could do something where a button is getting a background color of a variable. And then that variant could then change the variable, not the background color itself. Because that variable can then be used for other relative systems, like you mentioned,

• 48:34Scott Tolinski?

  the border radius, the box shadow, those types of things. And then therefore your variant code doesn't end up being a whole bunch of CSS property definitions. It's like a one CSS custom property override and that's it.

• 48:48Wes Bos?

  That's, that's so key. Cause like, sometimes I look at these things and it's like, you just made variables for every single property that existed. And now instead of setting border, uh, 10px solid red, I'm updating variables called border width, border color, border style, you know, and it's like, you just reinvented CSS and, and put them into variables. Um, but if you can look at it in terms of a way that is computed, where you're simply just changing one value, or one thing we didn't even talk about is like passing in CSS variables as, um, like inline style values.

• 49:28Wes Bos?

  If, if you want a variant for something, a great way to do that is you can simply just pass in, in inline style variable and then that will overwrite it and, and compute its way out.

• 49:40Scott Tolinski?

  I feel like I could talk about this stuff all day, Wes. I feel like I could talk about it all day. But we don't have all day.

• 49:45Wes Bos?

  Don't got all day. We gotta wrap it up. Let us know down below what your tips are for writing maintainable CSS or maybe some of the worst CSS you've seen your coworkers write.

• 49:56Scott Tolinski?

  Yes.

• 49:57Wes Bos?

  Peace.