 Hi, and welcome to the CSS podcast. This season, we're answering your most burning CSS questions. And today, we're covering a very common CSS issue, which is, why do I have a scroll bar here, especially that dreaded horizontal scroll bar in the body that nobody wants because it jinks your page around as the users are trying to scroll through it. So I know that an unwarranted overflow can be super annoying, whether it's tracking down the cause or finding the right way to solve it. But we've got your back. Oh, we've got your back, as usual. And as usual, I'm overflowing with a desire to overshare, overanalyze, and overcook today's episode on Overflow, episode 34. It's all about overflow, and I had way too much fun writing that. So if you're looking for an episode on how and why for overflow, check out episode 34. Definitely start there if this is kind of a new concept for you. But for today's episode, we are debugging it. So let's start with a few scenarios to help give some context to the topic. This one gets me all the time. You're embedding a code snippet into an article. And then on mobile, it's causing horizontal scrolling on the whole page that has repeatedly. I think it's because we write code snippets a lot. So maybe we run into that more than other people. Yeah, I agree. And it's like, I also use Flexbox a lot. And it's especially hard when you use Flexbox. Anyway, maybe we'll get into that. Another scenario is border or padding sizes are over contributing to an element's size and causing a scroll bar to appear. Maybe that's happened to you before. Or you just gave up and added overflow ex-hidden to the body tag, skirting the issue that you had under the carpet and acting like it's not there. So with those items in mind, let's start with that first one, which is why embedded code snippets are so tough to manage with overflow. And as I mentioned earlier, this is something that I have to manage and Adam has to manage a lot with either doing code slides or presentations or even in code blocks like for posts, like articles across the web, which can get annoying. So code snippets, they can go inside of pre and code tags, which usually have whitespace no-wrap or whitespace pre, making the text ask for a width that's as long as the longest line of code as written. So that might be how it's written in the text editor. But there are a few things that you can do here. And the first is to apply whitespace pre-wrap to your pre tags so that it actually forces a wrap when the page gets smaller than you have that long string code. It actually forces it to wrap, which I tend to do because nothing is static on the web. It's always dynamic, so I prefer it to wrap. But the second thing that you can do is if you don't want it to wrap and you want a scroll bar to appear instead, you need to change the element's ability to shrink in width. So let that element shrink and let the text sort of flow inside of it with that, get that scroll bar so that the user can see, like the whole line of text, which is also valid and valuable in many cases. So this gets really difficult when pre tags are inside of a flex container too because flex items won't shrink below their minimum content size, but the fix is adding minimum inline size or a minimum width of zero. So you basically tell the pre tag, hey, it's okay to go below the minimum content size. So you can go below the width of that minimum content. And this fix is also the same when you have grid layouts where the elements aren't squishing down small enough and you just have to give them permission sometimes. So it depends on your content and how you want it to present. Nice, well said. Yeah, that has really got me so many times because we have white space saying I don't want to wrap. Like all the code snippets on my website don't wrap. They scroll instead. So this thing is saying, I demand to be as long as the line as I was originally authored. And then flex goes, well, I don't shrink things below their requested size. And I'm like, do it, allow it to go down. And yeah, you explained that really well. I think that one has tricked people for hours on end. I've seen so many Twitter threads and a very nice breakdown there. Okay, so our item number two is depends on your content, but there's a common theme in this episode. And I like this next issue. You've got a div with display flex on it and the children are set to not shrink. And the layout was fine with two elements, but the CMS added a third. And now the third element pokes out at the end of the layout. So flex doesn't wrap by default. You have to tell it to wrap. So new items will just depend forever, which sometimes might be what you want, like if you want to create a scroll area. So you have to tell it to do something else if you wanted to do something else. And also the children are set to not shrink. Like we were just discussing. So they want to just to make room for the new item, we had two items that said, don't shrink. We added a third while they're not going to shrink to fit. They're going to continue requesting for space. You could use flex basis instead of telling them not to shrink as this sets an optimal size, but allows shrinking or growing to happen as more or less items appear. But like all in all, it's important to note that a flex layout won't wrap by default and won't shrink items below their mid-width. Yeah, that's a good call. It does get tricky when you start changing the layout model of these things because the different layout models have different rules. So it's one of those tricky things that we also talked about in previous episodes on this season of how things behave differently. So for example, with margins, you normally get margin collapse and block context, but then in grid layout and flex layout, you no longer get that. So just have to be aware of, it's really trial and error in a lot of cases. Sometimes, yep. So let's talk about item number three, which is horizontal overflow. And this is probably one of the biggest frustrations I had when I was learning to code and trying to build websites and just that dreaded horizontal scroll bar, like that was the thing. So one thing is if you use 100 VW for your width, and now you're testing your site and you might realize that your page has horizontal overflow, one thing that it might be is the operating system. So this is a common issue when you're building apps on Mac devices, you're not testing on Windows necessarily because Mac has overlay scroll bars on by default and Windows has inline scroll bars on by default. So 100 VW doesn't take that into account and you'll end up with a div that's the width of the viewport plus the scroll bar. So yeah, that's also another thing with like iOS and Android devices when you're testing between them. Sometimes there's differences in how things present with the scroll bars and that might cause scroll. So just test across devices and like the first solution might be to use with 100% but sometimes that actually doesn't work either as expected. So another solution is just to kill switch it and add overflow X hidden on a parent element which often would be the body element. And that's why a lot of people end up putting overflow X hidden on the body element. It's sort of a kill switch, but it does work. You know, no shame, but it is like, I mean, I won't lie. It's like a pro status marker if I load a site and they didn't do that, I'm like, ooh. Yes. They spent time to not do that, you know, but it's not really distinguishing the advanced version from a beginner. It doesn't solve the core problem. And the core problem might also be just elements that are overflowing like an article or like an area. So like an area within the page. So you might wanna apply overflow X within the page not necessarily on the body and try to find what the root cause of that issue is. If you don't have overflow X hidden on the body, you can sometimes like, if you see this where you're testing, kind of scroll over and try to find which element it is that has the additional space that it's taking up, which sometimes is the hero section or the nav bar. Like those are common little components, not little. Those are common components that end up causing that extra scroll. So check those out first before you do the kill switch, but, you know. We won't be mad at you. We'll be giving you some tools. Yeah, we won't be mad at you, but we will give you some tools to help you find those stinkers. Yeah, end up tools. Right, those stinkers that are popping out the horizontal flow. There's two more examples here we have for moments when you might be getting unwarranted horizontal overflow. One of them is images. If you don't have max width set to 100%, you will take the natural size of an image and maybe it's huge. And if it's huge or maybe it's not huge, but when you squeezed it down to a smaller viewport, it was bigger than the viewport. Hence overflow happening. So set your max inline size to 100% of your images, which is pretty much staple in a reset or your base styles these days. Oh, I always do that with images. Yeah, because default images just take the size of the inherent image. And that's never what I want. Rarely, rarely what I want. Yeah, rarely are you showing a natural image. Yeah, I totally agree. Another one though, this one gets me too, because I thought it used to be different, but it is how anyway, whatever. Let's say I rotate an element with transforms and then I got a temporary overflow scroll bar when the corner, right? You rotate a little bit and then the corner of your box is now poking out farther in the width than it was before, exceeding the parent's bounds and causing a scroll bar. And then it finishes its rotation and it's back to a box and there's no scroll bar. This has gotten me a lot of times and it's common, at least it was for me to think that transforms don't contribute to reflow or layout sizing, but they totally can. So be aware that rotating something or translating something can impact flow and potentially cause overflow. That's a good tip because that can especially happen if you're doing things like data visualizations or if you have interactive content, you might get like a little, if something is rotating and it's long, for example, it could create that scroll bar for like a second and then it goes away and then it comes back. And that's an even worse experience if you see it disappear, disappear, disappear kind of thing. So thing to watch out for, for sure. It's almost like something to build if you want to annoy people. I'm almost like on April Fools, I think I'll make something where it's horizontal scroll bar just like, yep, troll people. So let's wrap up with some tools and tips. One thing is to really think about why you're using width or height specifically. So in today's world of responsive design, you probably rarely want something that has such an absolute size. So consider instead using max width, max height, min width, min height and use aspect ratio to retain the aspect ratio of that content or image but don't give it an absolute position. It really rarely do you want something that's always the specific size. You might for smaller pieces. So for smaller things that, for example, wouldn't necessarily change on desktop or mobile, you might want that, but think about using more dynamic sizing values that are less likely to cause overflow. And the other thing to remember is that min width zero trick, which sounds funny, but it gives permission for the children of a grid or flex box layout to shrink below their min content sizes, which is the default. Excellent tips. The max width and max height, like that one's really important to me too because when you specify width on something, it's a very strong request. You're like, the width is this versus max width and min width, which are just sort of more gentle and they allow some flexibility. So that's why using width or height can get you into trouble because there's such a firm request. And it just doesn't feel that way when you write it, but it totally manifests itself that way. Well, there's two more tips here. These ones are more like DevTools tips. So the first one is Visbug. I love that Visbug is coming up so much. I mean, it is a visual debugging tool. Well, you did write it in. And I wrote it, yeah. And I knew that a lot of these problems were what people are debugging. Yeah, which is why you added them to Visbug. We need a tool to do this. That's why I added it. So there's one in Visbug you can find and visually mark all overflow culprits. And this can like drastically reduce your debug time because you don't have to go through the elements panel. You don't have to do what you mentioned where you kind of scroll over and look to see who's cliff hanging. Cliff hanging, I like that. Yeah. Got a Rambo over there. But it makes it easy to spot them and see what's exceeding the scroll area. And I think all you do is go to the plugins and type overflow and it'll highlight anything that's overflowing the body. Polypane also has a similar feature and it's a little bit more robust, but it will also go through and tag things that are sort of have overflow and show you the bounding boxes and give you an opportunity to sort of debug which one's doing it. And the last one here, there's a Firefox feature where they put an overflow badge in the elements panel on anything that is scrolling. And this can help you find and see the scroll port and determine which element might be exceeding those things. And you can debug it inside of Firefox too. Nice little call out to dev tools across the board. We got three different tools in there that I'm just hollered out to. And of course you could check out Chrome DevTools as well for trying to figure out what the item is that's causing the root of your problem. I don't want to experiment with, but like debug. Debug is the right word there. I like the culprit. It's like who's the culprit? Somebody's doing something wrong and I need to find them. Well, our overflow episode is over. So that's all. Oh, that's all we have for you today. Thank you for joining us. And if you have any CSS questions we'd love to answer them on the show. Just tweet us with the hashtag CSS podcast. Tweet us, toot us, skeet us, whatever the thing you're on is, find us, use the hashtag CSS podcast on Twitter. I'm Yuna on BlueSky, I'm yuna.im. And I'm Argyle Link on Twitter and I'm nerdy.dev on BlueSky. Your question can help a lot of people. And if you liked this show, please give us a review on whatever podcast app you're using or a like if you're watching it on YouTube. Feel free to give that little thumbs up, little thumbsy thumbs up, or share this with a friend or a coworker because those reviews and those likes, they help people discover our show, they help the show get put into the algorithms that it recommends to people, which is how people find it. And that means that we can help more people and it helps us have more time to deliver better content for you. All right, so if you don't want us to help more people, do nothing. If you want us to help more people, do something about it. Yeah, Adam with the gills. Thanks for listening, everybody. We look forward to your questions, though. Bye, y'all.