Why Your CSS Sucks

Welcome to Syntax on this Monday hasty treat. We're gonna be talking about why your CSS sucks. That's right. We're gonna be going through some of the reasons why you might be writing bad CSS and what you can do about that to change that. So that way, you can write, well maintainable, you know, nicely readable. And then CSS is gonna make your coworkers happy. As always, my name is Scott Tolinski. I'm a developer from Denver. With me, as always, is Wes Bos. What's up, Wes?

Hey. As someone who writes a lot of sucky CSS, I feel like I have a lot to bring to this conversation.

Love it. Love it. Hey. I don't know if you saw this, Wes, but, Canada won the gold for men's breaking or also known as breakdancing in the Olympics. Yes. Canada.

Phil Wizard, who was, he's a kind of a favorite to win. He he hasn't ever won a world championship before, but he's been close. So him winning is not a a shocking surprise, but I I thought you might like to know that. Wow. Well, that's cool. I didn't realize. Can can we talk about,

the all the drama that went down with the Australian element? I know I know that it's, I'm so tired. Yeah.

It's currently progressing. You know? There's people there's, like, people are thinking that she, like, scammed her way in. But all of that aside, thoughts on the Australian, and can you explain what happened?

Yeah. So okay. For 1, breaking is oftentimes goofy. You Node, it goes back into history, Frosty Freeze, one of the, you know, one of the original, Rock City, maybe not 1st gen. He might be 1st gen. Either way, old old school rock, Rock City Crew Breaker, very goofy style. Now he's a legend of the the the game and everything like that, so it's not he's not Ray Gun. But it can be goofy, and it can be weird. I've seen more weird dancing than I I saw from her at the Olympics. That JS, like, does not scratch the surface of weird dancing and breaking.

That said, Australia was given 2 spots, 1 for the men's and Node for the women's, and they won those spots fair and square in their qualifiers. It just so happens, that the skill level on Australia is different. So when people saw those video clips, man, that's a a qualifier. So she was doing that in a qualifying round.

And what sucks about it is they ignored all of the other incredible like, the general public. You know? I think it's starting to see a little bit opposite of that Node, but, like, people were ignoring all the crazy stuff that people did and just focused on this Node weird kind of set. So, one, in the breaking community, even if somebody is not doing well in a battle, their their punishment for that is they don't they don't get to move on. But you typically like, if I'm if I was battling somebody and they were bad, you'd still be, like, kinda clapping for them and say, you have a good job. And then you go and smoke them, and then they're gone. Right? So so the outside opinions of people just being so harping on this poor person is, like, yeah. That's not Wes we're about. You know? But I understand all that,

but there's not much I say, like, I could do that. You watch the Olympics. Oh, yeah. Node could I'm pretty sure I could do Oh, yeah. I could do that.

And there's she's the best, the absolute best in all of Australia? You're telling me? Do you know what? There's no one better?

For for the the ladies, I you know, it's it's tough with with, you know, b girls and and women's breaking.

They they're Like, I saw people on TikTok just replicate the entire

Oh, Wes. Session. No. It's it's it's a combination of a few things. You know? In breaking, you can get a lot further in competitions just being musical even if you're not doing anything, like, cool. So that gives people who can dance to the music, like a better advantage in competitions like that. So theoretically, she could win a competition just by being on the music rather than doing, like, crazy cool things. And women's breaking, especially, has only seen, like, an uptick in, people doing the power moves or the spins or the the tricks and, like, I don't know. Like, women have been doing head spins for a long time, but, like, things like the air flares and the flares. So those are, like, brand new inside of women's breaking in the last 4 years, 3 years ish. So yeah. I mean, there is a chance she is the best women's breakdancer breaking, b girl in, in Australia. There is a chance of that. So, I I don't know. The scene there is is kind of is even even, you know, the men's competitor, the that b boy, he was fine, but, like, he was also not at the same level as everyone else. And he was out very quickly. So, yeah, I think it's just a a matter of a a perfect storm. And You think a country that's upside down would be pretty good at breakdancing.

But no. I I actually got, breaking shoes from Nike. They made the 1st ever breaking shoes for the Olympics, and the swoosh is upside down on them. And I thought that was pretty great. Oh, that's great.

Man, well, I very, very, very thoroughly enjoyed all the memes coming out of that. I don't. I would Scott. The poor girl JS probably feeling absolutely awful right Node, but I loved all the memes where people are like, my toddler at 3 AM. And I was just like, god.

As the moderator of the b boy subreddit, I did not like the memes because people are just flooding the stupid subreddit with those memes. I've had to ban people left and right. So oh.

Oh. Well, that's that's great. Let's talk about coding for a for a bit. Oh, but before we get into it, if your code sucks, you'll wanna use something like Sentry to make sure that you have your errors. That way, you can solve them. So head on over to century.i0forward/syntax.

Send it to me to get 2 months for free. Again, if your code sucks or even if it doesn't, you'll want something to let you know it sucks. Alright.

CSS.

I think we've all experienced working in maybe legacy CSS or somebody else's CSS.

There's sometimes, you know, I wanna contribute to projects. I have a really hard time with this, Wes. If I'm using, like, an open source tool that exists for instance, there's a guy doing an open source hockey contracts tool. Like, the the tool that showed all the contracts and the salary cap just got acquired by one of the hockey teams. So somebody's making an open source one, and I wanted to contribute to that. And gosh darn. The project has only existed for, like, a year, and the CSS is horrific. And I don't like, I I have a hard time not wanting to go in there, just deleting it all and and trying to help them. But a lot of these things that we're gonna be talking about in this episode are things that I've personally experienced in other people's code bases or maybe pnpm, previous Scott or maybe even current Scott has has authored things this way. And it definitely can cause issues down the line. It can cause maintainability problems. It can be frustrating to work in for a lot of reasons. So we're just gonna be listing off a few things that could be, you know, the reason why your CSS is hard to work in. So number 1, you're styling the wrong element.

This is something I see all the time, especially with people who don't write CSS very often.

Let's say you have yeah. Here's a here's a Node, like a pagination. Right? You have a pagination that's a bar full of buttons.

And somebody would say, okay. This is an unordered list. Right? So then they give the unordered ESLint, like, a height of of 100 pixels. I know that's an outrageous value, but let's say they do that. Then they do their allies. They, you know, put a display flex on them or even worse, they they float them or something. And something is not filling the height correctly.

So what do they do? They maybe throw that height 100 on the list item and then maybe the height 100 on the anchor tag. And Wes thing you know, you have a giant mess of things where if you go to change the parent, the children are still popping out. And I see this all the time where where people, they style the wrong thing. They give the wrong thing the height. They give the wrong thing, the display block or whatever. And then, therefore, they have to do that again up a level or down a Vercel, and they keep doing that until it looks the way they want it to. So how do you fix styling the wrong element? I think it's really just, 1, it's experience ESLint knowing what to style. But, 2, if you do notice that start to happen, like, hey. I put a height 100 on this thing, and the child is not getting that height. So then I'm throw it if you notice yourself doing that, stop right away and remove it from the parent and put it on the child because the parent typically will adjust unless it has a hard Node value to fit the the child. But if the child is big, then the parent will have to grow, unless, of course, it is explicitly given a size, which means, you know, you have some issues.

When I taught, I would always say this thing, which is embrace the flex or embrace fluidity in in CSS, meaning that do Scott hard code widths and heights on too many things.

Allow the content to define the size of it. You can certainly put max widths and min widths and and flex values and and padding and margin on on everything.

However, as soon as you give something a hard value, you're sort of closing the door for other situations to to come up, and that's going to end in a world of pain. I see it all the time. Even if you look at, like, Chrome DevTools, you inspect the CSS on there. There's so much stuff in Chrome DevTools that was has a hard width and height on it. And then as they're trying to make dev tools a little bit more fluid and be able to scale up and down, I've noticed over the Yarn, they've had to take a lot of that out because it's just too too rigid. Let the content speak for itself.

Yeah. It is it is funny. And this can also even happen beyond sizes. It can also happen with, like I see this a lot times with background colors too, where, like, somebody will throw a background color on the nav and the header and the body, and those colors are all the same thing when they don't need to be. Right? Don't worry about putting a background color on something that's deeply nested if its parent has that same background color. That's just gonna cause a ton of problems down the line if you, want to change things at any given time. Yeah. You find yourself

Scott being flexible enough. You find yourself having to overwrite that in the future. Whereas if you simply just left it off or if you simply made a stripped down version first, then you can go in and add on top if if you actually need that in the future.

Yeah. So, this is a tough one because some of it is just feel, and you get used to these sort of things. Yeah. But if you notice yourself setting a value on too many things or having to override or constantly having to, increase how many properties you're adding on things just to get it to look the way you are, chances are you're you're styling the wrong thing, and you Node either take a step back or take a step forward into what you're styling specifically.

Next Node here is you're nesting too deep. It kinda comes along with what we just said is that if your selectors are so deeply nested inside of each other, you're going to find that your styles are a little bit too rigid, and it's much harder to overwrite.

And your components are not as reusable because you're assuming that this button is inside of card, inside of a pop up, whereas Mhmm. You should really be thinking, how can I apply the styles to this element as directly as possible so that it doesn't assume that this element will live inside of another parent? So I have hit this one so many times in my career. Even my own my own website right now is in style components, and I'm just dipping into figuring out how do I I'm moving that to Panda CSS, which they have an Wes that will change it. It it will like, I don't wanna rewrite my CSS at all. I just wanna keep the style of the API, but I wanna use the Panda to generate the utility classes for me. And, like, the I use not a lot, but a fair amount of of nesting inside of my components, And the resultant h CSS and HTML is not great. And I'm realizing, okay, maybe I shouldn't have nested that so deeply. Maybe I should have busted that out into its own component, Got busted Bos. Node. Yeah. I I tend to not bust things out as fast as possible

until I explicitly need to. Yeah. Yeah. I get that. And even to go along with that ESLint too deep is to understand specificity in a way that, like, you you only wanna be as specific as you need to be when applying styles to something.

And scope styles can help with that because they're very, specifically stuck onto an element. Right? If you're you're scoping really tightly. But you wanna be able to understand the impact of how many different, selectors or things like that you are adding into a chain of things to select a specific item and things like important. Right? Important is the classic number one CSS code smell. I, man, important is pretty much typically used for overriding CSS that you cannot access. And that's it. If you find yourself using it important to overwrite your own CSS, it is a major cause for concern that your specificity is is kind of out of whack in terms of what you're trying to access.

So, obviously, that's a code smell. But being able to understand, you know, classes Vercel nested classes, versus IDs, versus important, versus, you know, element selectors directly? What does that specificity order look like, and how is that impacting your CSS? Just having a basic understanding of that stuff will will take you quite a bit.

And and realizing, don't when you understand what makes something more specific and trying to stay away from it. Because if everything is just a class or if everything is nested 1 or 2 levels deep, then you're not gonna run into too many issues where you're sort of battling.

Yeah.

This is the word I can never say. It's spec specificity.

Specificity? Yeah. Yeah. That's your classic, but, you know, as bad as you are saying it, I'm bad as a typing it because I could not spell specificity this morning. I was, like, typing. I was like, I could say it, but I can't type it. Specificity. I think I did it. Specificity.

Specificity.

Specificity.

Yeah. I'm healed. Yeah. You're healed. Nice. Congratulations.

Time.

Yes. Next 1 we have here is, your classes don't use a system. So we did a show Node 807, syntax.fm forward slash 807 on the different ways to sort of author your your CSS and author your components.

And there are many different ways to approach it. Right? You can use Tailwind or Panda or Scott CSS or modules or variables and classes, and there's lots of different ways to do it. The important part is that you're not just sorta cowboying it, adding classes to random stuff as you need it, whereas you have a little bit of a a system, a little bit of an approach to this type of thing.

Yes. Yeah. And and that doesn't mean you need to use BEM or even anything that concrete of a system.

But let's say you are using, like, a Scott CSS system and or even, like, your utility based CSS system or any of this stuff and you need to add a class.

You Node? It's important to know just the general way in which that class should exist because somebody could go in and add a class that is it is using BEM. And somebody could just go and add a a straight up class. And somebody could use it as a single word class and stuff like that. So even if you aren't building your entire CSS based on, like, a CSS class system, it's still important to have a general style in which you're adhering to the way you have your class names. I just think that's important, and therefore, everybody will kind of know what they're doing.

Another big one here is using values instead of CSS variables. And this is for all kinds of things, whether that's font sizes, colors.

You Node, tons of things are important to set once and then use the variable because you can have situations where all of a sudden you're you're adding bespoke font sizes because you're old. This font looks nice or this font size looks nice. The next thing you know, you're not working within a system at all. You're working off of it looks nice.

And that can be okay in small projects. But the larger your project gets, the harder and harder that will be to maintain over time. If your system does not include the size that you need in for your fonts or the color that you need, you don't add it in a one off case. You adjust the system. So you either add it as a systematized variable or you tweak maybe you have a font scale. Maybe you tweak that font scale to make the whole thing look better or more like what you're trying to accomplish.

But, again, especially with things like colors and font sizes, font families, those types of things, there's there's a massive amount of things where having a CSS variable is not just good for, maintainability, but it's good for readability. It's good for consistency.

And most of the time, you'll make refactoring easy if you ever need to refactor it. There's so many benefits to it. I always talk about how websites

rot or websites drift. CSS sort of drifts, meaning that, like, oh, we have this color.

And, oh, somebody used the color picker, and it didn't get it bang on. So it's a couple hexes off. And, oh, and somebody wrote in RGB and or someone used another color picker. And over time, these things start to look a little bit different from each other. And over the scope of a year or 2 on a large project, you've all sudden added a whole bunch of CSS that is very hard to maintain and is not as consistent across the board as you want. You know? That's why we have a lot of these design systems, which are very rigid.

And a lot of times developers don't necessarily like them because you have to work within the confines of it, but it will stop that drift or that rot over time.

Yeah. Which it it's very real. I think we've all seen it. That that thing about the, color using, like, a color picker and then just getting it ever so slightly different, And that is is too real. I I've been in so many old code bases that have, like, you know, even 5 or 6 different slightly different hex values that it's like, if you were to just throw one of those in the variable, use that variable,

it would solve you so many issues down the line. Or I had that that problem for many years where I use my yellow, and I have a keyboard shortcut for my yellow. And I just type colon yellow, and it auto completes it.

And I had to, like, stop myself from using it because I realized, like, this should be a variable. You know? Even though I know it's my yellow, and I could do a find and replace because it will be the same thing every single time.

Even if you wanna theme it, you wanna do a dark Node, it's much better to have just a single variable. And even then, you go, like, the syntax yellow before we what was it? Before we printed the skate decks for the syntax, I I tweaked the yellow just a little bit and Went brighter. Right. A little bit brighter. It was a little bit too washed out, and I was glad that our website used variables because I was able to go into the website, click on the variable, and just drag the slider up and around a little bit until I go, that looks good. And then I was able to change that one value. It's so much easier to do that than to have to, like, find and replace every single value. And, oh, I didn't get that one instance. Now we have yellow that's we have the old yellow and the new yellow. You know? Pain in the butt.

Yep. Another big one is understanding, or you don't understand block Vercel inline versus inline block.

And, therefore, you're either using HTML elements with the wrong default thing and you're applying block and then you're applying inline block. You don't understand, so you're just kinda throwing at the wall until it sticks.

So having a good understanding of what ESLint and what block and inline block means inside of the context of the document flow will make you a much better CSS developer.

Also, important now and that we have things like, you know, padding in line or, you know, margin block start instead of margin left, margin right. We're no longer thinking about left, right, top, bottom. We're thinking about ESLint and block in a top, top left, bottom right situation.

CSS logical properties that's referred to if you wanna look that up. We've referred to it many times over the years.

Yes. Yes. Yes. Next one is you're not using the right tool for the job. This one's, like, I guess, a little bit subjective because there's always more than Node way to to do the job, but you got Flexbox, you got Grid, you have CSS columns, or even just like you're not using the right elements for the job as Wes? Are Yarn are you using a link where it should be a button and vice versa? Are you putting a div where it should be a details dialogue? Being able to understand what the landscape of tools are out there and keeping up to date with CSS changed a a whole lot in the last 2 years. Do you know about all of those new things so that you can

tackle them? Yeah. And in regards to the Flexverse grid thing, I do think there are some people who learn Flexbox once and have just said, I can do most things with Flexbox.

Yeah. But there are times when a a grid is more than appropriate, and they and then so instead of learning grid and sitting down and and using the right tool for the job, they're going to, use Flexbox for something that is maybe a standardized, x y, you know, grid. And they're gonna try to use Flexbox. And the next thing you know, you got, flex shrink issues and all kinds of weird stuff because, it's not necessarily

the best tool for that job. Let let me ask you about Flexbox versus Grid. When you're tackling something and it seemingly Flexbox and Grid can do it, what's your approach? Do you default to 1 or over the other?

Yeah. I mean, I think about almost like a, a if it's in one line, I'm almost always using Flexbox, where if it's, everything's staying on one plane, to me, that is like a default to Flexbox.

But if it starts to get into 2 axes and I need control over it, that's a grid situation for me almost a 100% of the time.

Not to say that you can't use Flexbox with wrap, but Yeah. Typically, when you're doing that, it's when things are not standardized. And let's say you just have, items that need to reshuffle and flow into the next ESLint, and I'm gonna reach for Flexbox. But if I Node it to be standardized, I need it to be a specific width or size or percentage, then I'm gonna reach for grid almost a 100% of the

time. Yeah. I will default to grid on absolutely everything, and then only go for flexbox when the elements in the axi are different sizes and Yes. Likely need to wrap.

So if you have a big item and then 2 small ones and then a really big one, and then on the next line the thing about grid is that every column needs to be the same width, whereas Flexbox, every single row can have different sized columns. They're just they're they're not even columns. The the items are just,

flexing to how big they need to be. I think the different size thing is an important distinction there. Because in in grid, yes, things can be fluid, but you typically have an understanding of some kind of standardized size. And with Flexbox, it's like, these things could be any let me just shove a bunch of stuff into this area, and it's going to adjust.

Next 1 is you're setting the value in too many places, and this goes along with your styling the wrong element. If you notice that you're setting a value on several things to accomplish one thing, that is an issue.

So that goes directly along with the styling the wrong element Node.

Alright. Last one we have here is you're scoping too tightly or not tightly enough. And it's true. We talked about that in our components. One is sometimes you are scoping things too tightly Wes if you wanna be able to reuse a component in another spot, you're not able to sort of move it around. Then sometimes you're not doing it tightly enough where you apply some CSS to an element on the page, and then, oops, that accidentally has leaked out or that, oops, that's accidentally styling some other parts on the page. So knowing where that sweet spot is and, again, this type of stuff, I think it just comes with experience.

Yeah. It it comes with experience.

But, also, you'll you'll notice if you're constantly having to override things or you find yourself writing the exact same CSS in multiple places. Like, you're inside of a a component, and you find yourself writing the exact same CSS you wrote inside of another file that's tightly scoped, then you're thinking, alright. Maybe this needs to be a Sanity class or just a class itself or or maybe this should be a component even, and then it can be scoped to that component. There's a lot of different ways to solve this issue. But if you're scoping really tightly and you find yourself repeating yourself, that could be a problem.

Yeah. We always say dry Node, don't repeat yourself.

And, like, I think it's it's fine, and you probably think this. It's fine to sometimes repeat yourself. Like, sometimes it's way too much work to create this crazy abstraction because you wanna reuse 12 lines of CSS in 2 different spots on the website. And sometimes it's fine just Scott paste the thing and edit both of them if you need to change. But in other cases, you you find yourself, oh, I've duplicated this thing over and over again. Like, for example, on my Wes, I have this, like, grit texture that is in, I don't know, 50 different spots on the website. Mhmm. And I found myself going, oh, wow. I I have applied this background background color, background repeat, background size on, like, 6 or 7 different spots. So I stopped. I ripped it all out, and I made a utility class. I simply just pop grit on an item, and anywhere that I pop that on will get that effect. Awesome. Yeah. Yeah. Totally. I I think this is, again, Node

you'll get with with practice. But, yeah, like you said, you know, there is an extent where repeating yourself is is certainly appropriate.

You Node? I think there's context in which you're you're worrying about a big site with a lot of people working on it. And then, therefore, dry code becomes more important, rather than a medium to smaller sized sites where it's less of an issue. What's the acronym for sometimes repeat yourself?

Or strike Node? Fry code? Strike Node? A few times to repeat yourself is fine. Fry code.

Few times. We gotta take it. Can we ask ask an x f m? What's what kind of Node is, well, maybe that is rye code where you repeat yourself a few times Yeah. But not too many. Don't drink too much rye. You know? 1 or 2 glasses of rye is fine, but

too much, it's not a good day. You're feeling it. Yeah. You're having a you're having a some some problems.

Alright. Cool. I think that's it. That's why your CSS sucks. If you have any other reasons why you think your CSS sucks, let me know. We can talk about those on the show, or we can maybe just, you know, have a deeper understanding about why people's CSS sucks and, what sucks about it. So thank you so much for watching, and we will see you in the next one.

Peace.

Peace.