Kevin Powell edits
===

[00:00:00] Hello and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket helps software teams improve user experience with session replay, error tracking, and product analytics. You can try it free at logrocket. com. I'm Noel, and today we are joined by Kevin Powell. Kevin's a CSS evangelist helping people fall in love with CSS.

We'll be talking about one of his talks today. Welcome to the show, Kevin. How's it going?

Yeah. Thank you so much for having me. I'm looking forward to it.

Yeah this will be fun. ~It's always,~ I always love jumping into people who are like passionate about CSS because they always have a lot to say it's always super interesting. Let's jump in what inspired you to talk about CSS at large and like the frustrations people are having with it in general.

Yeah, so I've been teaching front end stuff in general for going on a decade now, and I sort of specialized, especially online in the world of CSS. And one thing you start teaching it a lot. I realize people are frustrated by it at times and for a lot of different reasons. [00:01:00] But I really enjoy writing CSS.

I think it's a lot of fun. And so I started thinking about like, why do I like it? And there's other people out there. I'm not alone. And why do we enjoy it? But other people become so frustrated with it. And you know, instead of doing the whole, let's Hand a person a fish and feed them for a day analogy, right?

I want to teach people more of the big large scale things so they can enjoy it all the time instead of just here's how you make a navigation or here's how you make a card or whatever it is. Let's look more bigger picture and take away the frustrations. There's sort of underlying everything instead.

Why do you think CSS lends itself to these traps that people fall into, like this kind of deceptive simplicity and just this kind of I don't know, foot gun that CSS tends to be sometimes. do you think about it?

Makes it have that behavior.

Yeah. So I think a big part is the early days of learning CSS. There's so much of it that is you know, especially the very, very beginning, the [00:02:00] syntax is the first thing you learn and the syntax is really easy. And then you're going through like a couple of days of just like selector. Property value, and it's background blue color red, you learn about the box model.

So you start adding margins to stuff, but everything you do is really simple. It's one property, one value. It does exactly what you tell it to do. And every time you're writing it exactly what you write is what shows up on the screen. And so you get this idea in our head. It sort of conditions us to see CSS is this really simple thing.

I give it a command. It does exactly what I told it to do. But in reality. Once you get past those really simple things that we're trying to change and you get into actually starting to do layouts and starting to do things that are a little bit more complex, that simplicity goes away. So somebody will tell CSS to do something and then either it doesn't work at all or it does something but it's not what you expected it to do. And then you feel like CSS is doing something wrong because up until now you've been conditioned that if I tell it to do, change the color, it's going to work, or I tell it to change the [00:03:00] font size, it's going to work. And now I'm telling it to do something and it's not doing exactly what I'm telling it to do.

So I think we get conditioned into thinking that it's mucking up when it's not doing what we want, but there's this. The whole world of complexity that comes in because if I do a display flex, that's not one thing that I'm doing. It's not like when I change a background color, I'm saying display flex, well that's changing the display value of all the children that are inside of that element and then They turn into columns and then it's unlocking all these new properties and all these new values that I never had before.

And then the children get new properties and values that they never had before. And there's this whole extra complexity that comes in that we weren't really expecting in a way when we were doing all of the easier stuff earlier on.

Yeah. I think that's a, that's an interesting call out and observation. And maybe something we don't think about as much if we've just been in the CSS headspace forever, where it's like certain properties do overload the mental model way more put like, yeah, like you said, like flex versus background is a great example.

Like the impact [00:04:00] of what slapping flex on something versus the impact of changing the things background is so immense. ~Is there,~ do you think that this is like a shortcoming of CSS? Like, Is there something that could have been done here to make it so like, if we're doing something that's going to have like a very strong cascading effect, like down the Dom hierarchy, like to make that more explicit or like some other way that we could have.

made this more evident for people that are stumbling along for the first time.

Yeah, that's a really good question. I don't necessarily think so. I think it's just something that needs to be sort of explained when we get to that stage of things uh, properly. And just that, like, when we do this thing, there's a lot more going on with it. And just to appreciate the complexity that comes along with some of them.

I sort of see it as you have a lever that you can pull and push or something for like a control and you're doing like your property and then you're just moving that lever. But if you're doing something like display flex, when you put that lever into place in like position lever into the flex mode, there's 12 new levers that pop up and then there's another section of other things.

And I think we just need to prepare people [00:05:00] for that. And instead of just letting them figure it out on their own.

Yeah. If you had to give devs that don't do a lot of CSS or are trying to improve their relationship with CSS in this regard, in particular, like to have a better mental model of like how do I have to think about some of these selectors? Is there anything? You'd advise here to take a step back and help them assess.

Yeah. I think one thing to think about is ~it's. Very,~ if you're coming from like a computer science background, or you're writing a lot of JavaScript and stuff like that, where they're like, encapsulations are really good thing, you want to minimize side effects. And so I think that's the other thing it's the opposite that's sort of happening when I do display flex, you're causing side effects by doing that.

Yeah,

And I think in a way that might also be something that bothers people a little bit. But we have to live with that because that's A big part of what I think is like, you have to get into this like different mental model when you're writing CSS, it's like a different mindset that you have to be in because everything on the page has to be able to interact with the other things on the page, like that there is this just through the [00:06:00] nature of how layout works, like nothing can live in isolation, and so I think a big part of it is just it's okay that there's Cascades going on and these global styles that can inherit into other things and that if I do change one thing it can impact other things and That's probably a good thing because I think it would be really hard to do things if that wasn't how it worked but it definitely It just means like when you're sitting down to write some CSS, you sort of have to change the hat that you're wearing a little bit and change the approach that the mental approach you're coming into writing it with.

Yeah. I think that's ~a,~ an interesting observation if nothing else, because yeah, you're like encapsulation. So important,~ important.~ We're always like trying to write code with no side effects and all this stuff. But yeah when, ~when~ you step into the world of CSS or even like just displaying in the browser.

~We ~the reality is there is all this global state that's going to be changing out from under you all the time, and there's nothing you can do about it, so that like, the, ~ the, I don't know, the~ difficulty then becomes, okay like, what's the, or maybe the charge of CSS then is, what is the easiest way to wrangle this?

[00:07:00] Without going crazy ~driving yourself up the wall. ~Let's talk about some of those constraints and how those compare to other languages. Things like these browser attributes that we're talking about, like browser width and I guess viewport size like system settings.

I input method zoom, like all this stuff. how do you think of those constraints relative to, wait, say writing something like JavaScript?

Yeah, so what's interesting with JavaScript is like, if you don't write any JavaScript, there's nothing, right? Like you're building it up from ground zero. So you're basically in control of everything that's happening. And if you have a variable, you're defining what that variable is. And then You know, you can get into very complex things, but you're checking, if this, do this, if do this, if there's an error, do this.

That's not how we work in CSS at all. And like you said, with some of those constraints that we're working with, it's. Constraints. We have zero control over so we don't know what the viewport size is. If the person on a phone on a big screen, maybe they're on a big screen, but the viewport is still small.

~You don't,~ the input device is completely unknown. [00:08:00] Is it a keyboard? Is it a touch screen? Uh, Stylus and even then it gets into this muddy middle ground where it could be a laptop that ~they have a track. ~They have a trackpad, but they can touch their screen. Uh, They have some people will control it through voice.

You're using your keyboard to navigate. ~I don't know, right?~ right? The browser settings. I could say font size one rem, and then the user has a default either operating system setting or they have a browser setting that's changing the default font size, whether it's through zoom or through just changing the actual font size.

So I think that's the other thing is we have to. Approach it by going I don't know any of this stuff and I can't know any of this stuff and it's okay ~to~ And so instead of trying to account for every possible scenario Like you'd want to be doing when you're writing javascript You can't do that because there's too many things to try and take into account So instead of that, it's about trying to lean into that.

And instead of trying to work with absolutes, it's more about working with the browser and hinting the browser to go in the right direction based on like some you know, make your own constraints around it. Already [00:09:00] if you don't set a width on something block level elements, they're already just going to take up all the available width and their height.

Is height auto, it's going to be zero. And then as you add content, you get more, you make the viewport smaller. That height is going to increase on its own. You don't have to do anything. It's just doing that naturally. So instead of worrying about like, it's a simple example, but it's one of those ones where let's not fight against that behavior.

Let's. Take advantage of that behavior. I don't have to write any code and it already works and it's already responsive, but maybe I'd want to stop it from getting too wide. So you throw a max width on there or you need it. It's a hero section of your site or you need something that's taking up more room.

So you set a minimum height of a hundred VH or whatever, just so it takes up that space. But if the viewport is getting smaller, the content needs more room to grow. It's a min height. So it's still able to keep growing if it needs to, without causing any overflows. So a lot of it's about. Okay, let's see what the default behavior is and let's build on top of that just to make sure that we're working within something that makes sense for me without trying to set absolute values on anything [00:10:00] and fight against things and try and be super specific, because I find that's where a lot of people start running into trouble.

Yeah. Yeah. I think that there's something or I don't know, like an interesting kind of loop back to just writing more conventional, like process driven code here. And that like,~ I think we uh,~ developers often had this realization, like that ~as ~code as they can write, like that is the optimum amount of code to write.

Cause then there's like the smallest capacity for bugs to be introduced. And I think that People that are writing a lot of CS or have been for a long time, come to this realization as well. It's like the browser for the most part. We'll probably do what I want to do. So if I can like do the minimum thing to get this, to look the way that I want it to look, then it'll probably behave correctly.

or I think that the tricky part there is that, especially when we get a handoff from designers or something, and they're working in something much more regimented that it's like, okay how do I translate this cleanly? Without pulling all my hair out or being too specific in the rules that I'm defining where then I do end up ~in, in,~ in trouble ~when I want to, like,~ when things become responsive or a user zooms in or something [00:11:00] like that.

Is there anything that you can recommend to dev developers that are serving as that translator? Like, Okay, I have to take like a static thing a designer gave me, but then make it as minimally impactful as possible. So we can still rely on what the browser will provide us.

Yeah, I still think, what I mentioned before was a very basic example, obviously, with the max width and the min height, but I think that sort of idea can still translate over where I think there's two different things to look at. There's sort of like, am I styling the content or am I styling the layout?

Cause those are content will affect layout. So I think one thing that people do sometimes is they're like, they try creating a layout and then they change the font size and then it doesn't fit or there's weird things going on. So like start with the things that you know, are absolute set your font size, get sort of the basics down the colors, some of the general spacing, things like that.

And then you might have this component, but then like, how, where's that going if you're making a card, let's say, and you know, the cards getting plugged into a three column grid, or it's maybe they stacked, [00:12:00] but at larger sizes it's becoming a grid.

So like, do you even need to worry about things like a width on there?

Or is it just going to sort itself out? Because you're plugging it in, and it's following the grid there. So it's never going to get too wide anyway. So you set your font size, you set your border radiuses, your box shadows, you're doing all the decorative stuff, you're handling the content itself, and then you're worrying about, okay, how's this going to work within my layout?

And maybe you'll find that it works perfectly, or maybe you'll say like, Oh, in these situations, it's becoming too big. So that's where you go. Now I'll add a max width on there just to prevent it from potentially stretching, you start seeing these problems once you have it in context.

I think that's the problem some people do is ~they,~ especially in today's web, we're so component oriented. Everything is a component. So you're looking at these things in isolation, but nothing on a site lives in isolation. It always lives with other stuff going on. So you sort of need to build that thing out, but then see the different ways it's going to be working.

And then depending also, I think on where and how you're working, if there's something that's weird, or you don't know when it you know, as you said, we're getting a static file from a designer. [00:13:00] And maybe they're even giving you the mobile, it's a card, it's a single component, and they're saying it's small sizes, it looks like this, and when there's more room, it looks like this, and you don't know when that should happen.

If you're in the position to do it, mock it, make it, and then go like, when is this okay? Should it switch to a different screen size? I think that's an important thing too, that I think it depends a bit on company culture, and there's other stuff that plays into it, but when possible, if you can have open discussions with designers on stuff, I think that goes a long way too.

Yeah. ~Yeah. Yeah ~I think it is, it's a process typically and it's tricky. And I think ~yeah ~if one's in that position as well, it can be helpful because you also then have the power as the developer to come back and be like, Hey, if we can like tweak this one thing, like this all becomes way easier.

Is it okay if we do this? And I think it's really tough if you're, if one isn't in that position, but I think that's the reality of The technology that we're working with sometimes it's like the browser really wants us to do it this way. Can we like make this a little different here? You talked to some at the beginning of your previous response, you spoke on like setting attributes unnecessarily. And in your talk, you talk about useless declarations. ~Are those the same?~ Are those the same [00:14:00] thing?

I think, yeah, and sometimes it's a bit different. I see, I think it's more from beginners or maybe from people that are just, you're used to telling things exactly what they need to be. So you start declaring things. And as we said at the beginning, like a block level elements already taking up all of the available space.

But I, when I'm helping people and like my discord or other stuff, like I'm seeing things where people are saying with 100 percent and I'm just like, Oh, yeah. You don't need it there because it already is. And it's not even, there's actually a difference between a width of 100 percent and a width of auto, and ~ ~sometimes you might want the 100 percent and most of the time you probably won't notice a difference to be honest.

~ ~But there's like a small difference. If you add a margin to a left or right ~you'll find the difference. ~Uh, All of a sudden you get overflow and you're going, why, and it's annoying. And it's also because you don't. A lot of time we don't add margin left and right to stuff as much now, especially because we have flexbox and grid.

So when you finally do it and then it breaks, it's even more frustrating because it's not a common problem. So it's like things like that can be useless. I also see this [00:15:00] obsession with viewport units for like body 100 vh 100 vw for the width and height. It's sort of like that JavaScript mindset where I said, where you're starting with zero.

So you're going into the page and you have nothing. So you need to build everything from scratch. And I feel like it's that same thing where they're coming in. Okay. I need this to be full width. So I'm going to make it full width, but a hundred VW is problematic because if anybody's on a windows computer using Chrome, the scroll bar is not a floating scroll bar, and if you have a floating scroll bar, which I think every browser does on Mac, I'm not a hundred percent sure, but on windows, Chrome doesn't and.

The hundred VW doesn't account for the scroll bar. So it actually add a horizontal scrolling to the page because it's adding that space underneath the scroll bar that you then have to scroll and reach, which you don't want to have. And a hundred VH, even if it's just height, 100 VH, that becomes problematic.

It introduces potential for overflows and other stuff. And it's,~ it's~ just this thing of ~instead of~ let's. See what we're starting with. Cause we're not starting with zero. We have all these user agent styles that are doing lots of really good things. [00:16:00] There's a few annoying things in there for sure.

There's, things that we want to change that are stuck there. But overall we want to just work with what we're already starting with in the browser and just build on top of that instead of trying to. Just not thinking we're starting with a blank slate because we're not starting with a blank slate.

I think that's really important to know. So ~declaring thing,~ don't declare something unless you, like you're looking at it and it's not what you want. And now I want to change it into something else. That's when we need to declare something.

I'm curious, like ~what,~ what leads to this problem? Why devs do this? Cause it almost seems intuitive, right? Like I think most people it's like, well, of course I'm not going to declare things that have no purpose like naturally, but we find ourselves doing it over and over again.

why do you think this ends up happening? there

it's, I'm looking at my design file and I'm writing the code to make that happen and then I'm hitting save and looking to see 

~Why do you think, ~what it looks like on the side. So I'm not,~ I'm not ~focused on what I'm actually starting with. ~I'm~ so I'm not like worried. ~I've,~ I'm trying to build this thing exactly how I want it to be.

So I'm just building that up and it has these properties. So I'm going to put them in there. I've even seen [00:17:00] this and ~it ~with ~like font declarate,~ like font family or color declarations where I've gone in into code bases to help people and the re declaring like font family on every single element, cause everything's in like scoped CSS.

So it's like CSS and JS or something else, but like there is a global CSS file that's already declaring it. That font is being inherited everywhere already, or the color is being in, but they're still going in and they're declaring every single thing they need. And then, if ever you need to make a change, that's a nightmare at that point, because now there's no more inheritance going on.

You're, they changed the font family there, but it's not cascading down or inheriting through, and Then the maintenance of that becomes an absolute nightmare. But I think it's, you look at your design file. Oh, ~here ~Figma is telling me this is the font family. This is the color. This is this.

You're just plugging those values in and then realizing down the road that maybe I didn't need to do that because CSS was doing that for me already.

I guess. Are you familiar with or have you used like any tools that like, there would be more than just like a formatter or a linter, but something that's like a little more potent that can be like, Hey, [00:18:00] you're like redeclaring and a font's a good example, like the font family here.

And that's already inherited. Like you don't need to do that with how everything I currently see on the page. Are there any tools that do that?

That's a great question. I can't think of any that 

I can't either. Yeah.

and I don't know if the problem there is especially if it's just looking at the code, it doesn't know the context

It needs to be looking at the rendered browser. Be like, okay, Hey, everything I see here, like this is a redundant rule. Can we pull this out?

Yeah.

It'd be cool. If anyone's looking for a project idea or if anyone knows,

That could even, I could see an extension or something that could do that, because then, as you said, that could be looking at the rendered, finished version and then being based on that. That'd be interesting, yeah.

Yeah. Yeah. Cause I think it'd get you, it would, if anything, it'd be like a handy learning tool. Cause you'd be like, Oh, like I don't need to do this. Cause you could also then do things like with the browser, right? Like this is a redundant rule. Probably if it's on body you don't need this.

Is there any process maybe you recommend to help devs? Like. Not accidentally find themselves doing this beyond going into the browser and like toggling off rules they've added to see [00:19:00] if anything actually changes.

Yeah, I think just thinking to like what if I'm showing like if I'm working my way through a project or something how I'd approach it is again looking, always being aware of what I'm starting with. So like, if I'm writing a component or doing something ~like I'm going to. ~I'm gonna write the HTML, whatever, it doesn't have to be like vanilla HTML, you could be making a component in React or whatever it is, but I'm gonna put the content first, I'm gonna hit save and see what I have that's the first step, is like, let's see what I'm actually starting with, and right away I'm gonna notice, is it the right font size, the font family, all these other things like, I'm gonna see what's being rendered, and then I can go through and actually, okay, now, let's I need my heading to be bigger and now I need my paragraph needs a max width on it and I'm going to see the different things that I need to tweak but I'm going to layer that on top and make those changes because it's a visual language and we're writing code to visually change things.

So see what you're starting with and then change what you need to change instead of just force feeding everything in there.

Yeah. Yeah. I think that makes sense. I've found just like zooming in a little bit. I feel like we've, I've found most of our [00:20:00] discussion here, the hard bits we seem to be talking about Layout and positioning is kind of a thing that seems to be where we find ourselves the most frustrated and are the fiddly bits here.

Is there anything generally you'd recommend to help devs set out the down, down the right path on figuring out what layout tools to use in a specific situation?

Yeah, that's a really good question. And I do think in a sense, it's a hard one to answer, but I do think it's really important to some people are like, Oh, Flexbox does everything I need it to. So I'm not going to learn grid. And I see that in my comments quite often. And I've seen the opposite too, because people that are newer seem to, there's more people.

That start with grid now which I think it's a little bit different for all of us who were writing it before, because you almost felt like that natural progression that you do flex box, then grid, but there's definitely a generation now that are doing it the other way around. And ~they get ~they can get like 90 percent of the way there using the one they know well.

So they feel like that's good enough. But I think it's important to realize that we have two layout [00:21:00] tools for a reason. The analogy I like to make is to like a pair of shoes where, you're not going to wear your dress shoes to go play soccer with your friends. And you're not going to wear your soccer cleats to go to the office and walk around.

It's, they're both shoes. General purpose of them is the same. You know, We put them on our feed, but they each have very specific jobs. They do and with flex box and grid. It's a little bit the same way where each one has strengths and you want to lean into those strengths to make your life as easy as possible.

And the common thing that I hear is like the 1D versus 2D, but I don't really subscribe to that myself.

Because you can make 1D layouts with Grid and you can make 2D layouts with Flexbox, you put Flexwrap on something and all of a sudden it's wrapping right? So then it's, you're getting columns and rows, but it's more about the control of them.

So like, Grid is having full control on your,~ ~~on your~ columns and rows at the same time, whereas Flexbox is more like, I'm either controlling my rows or my columns. A little bit. So yeah, just realizing that you have the two of them and I see grid is more of like the structured one. It's you know, my parent is [00:22:00] laying out.

This is my layout and the Children are just going to do its thing and they're going to follow exactly what the parent is telling it. If it's you know, the columns are this size, it fits into that size. The rows are that size. It fits into that size. Whatever the Parent is outlining it has full control over it.

There's a flex box. It's much more like intrinsic and it's like, okay I'm gonna do a display flex and then i'm getting all these different sized items because it's Following the size of the items themselves and then I can put these new properties on the children to actually change the size of them, right?

Flex one and that one's getting bigger. I'm changing the flex shrinks or the flex basis. So it's the children are actually what are controlling the layout in those cases.

So the way I like to think about it is more like, which one do I want to have that control?~ Do I want to be controlling things through grid or do I want to be controlling things through sorry,~ do I want to be controlling things with the parent with a very structured layout?

Or do I want to let the children have a lot more. Say in how things are actually getting laid out,

~Nice. That's, I think,~ yeah, that's a, that's an insightful way to look at it. I guess part of, I don't know if I've seen this that much online, but I've definitely seen it and felt it myself is that earlier point we had about letting just like the [00:23:00] browser do its thing and be smart. I think a lot of people that are like much more they have a higher propensity to reach for like flex is because I think that it almost feels like if I use flex, I'm still like letting the browser determine where things go.

Or if I use grid,~ I'm like,~ I'm taking on more control and like saying, I want this to always be here, which does feel like it, I don't know if it is totally. Antithetical to what we were saying before of like, let the browser arrange things for us. But I think that there is, there's like something in that argument.

What would you say to those people that feel that grid is almost always like too regimented. 'cause we're gonna want to you know, yield control to the browser

right? Yeah, I think both of them can do it but Flexbox definitely by default It does that like you said and I think in that sense It's a good thing and you throw display flex wrap that aren't like We have these really complicated navigations, the hamburger menus and everything for mobile, like just put a flex wrap on there.

It's going to work, and it's probably fine for 95 percent of the [00:24:00] time, and a lot of people have an easier time with it. Your designer won't be happy. But other than that, everything's good. Grid definitely feels much more, as you said, forceful. It's easier to run into overflow issues because you've defined your columns in a weird way.

When I tell people that we should learn flex and grid, I think some pushback I get is they're both kind of complex, but flex, you can get working a little bit quicker, I think. So people like display flex, you see something happen, which is nice. But I'm like with grid, basically to start with and to cover most of the things you're doing, if you throw a display grid on something, Just understand I can define some columns and understand just the basic way of defining columns.

And then there's the auto fit feature we can use. So it's like the syntax of it's so weird. And I think this is what causes some people just look at it and be like, no, I'll stick with flex box. You do grid template columns, repeat. So functions, you have parentheses, then you have auto fit comma, 

then you have a min max, which is another function and then you put in a minimum size and then you have your one FR anyway, it looks funky, but then you're basically letting the [00:25:00] browser figure out what the layout is going to be based on the constraints you're setting. And it's, it leans into that idea that we were talking about at the beginning of like, instead of.

Giving absolutes. It's about giving the browser constraints to work within. So you're saying, this is the minimum size I want my columns to be. You figure out how many columns are going to fit. And I think it's a term that Jen Simmons coined called intrinsic design, where it's really about letting the browser do the heavy lifting as much as possible.

So by doing that, you're like, Oh, I want my columns to be 300 pixels. That's sort of ideal. But if there's more room, let them grow. And then, so it's going to be, okay, I only have room for one on mobile, but then as the screen gets bigger, oh, I have enough room to fit two of them next to each other. So I'll shrink them back down and put two of them next to each other.

And then it keeps getting bigger and now I have room for three and it makes three columns and that type of idea. And if you learn how that works and you learn the basics of just defining like a set grid as well, and then you learn the basics of Flexbox, you can do 95 percent of every layout that comes across without too much trouble, I think.

Yeah. Yeah. I think you're [00:26:00] right. I think the nuance there, the tricky part I think you can get there with either tool most of the time like, unless you're doing something really tricky, but I think that the nuance there is which one is better suited for this specific case?

Is there any kind of quick rules you'd recommend people keep in mind or anything that may be indicative that you're using the wrong one when you should be using the other.

Yeah, and I see this where people are like, I've literally seen the question of like, how can I get this to behave more like grid or how can I get this to behave more like Flexbox? And they're literally they're using grid and they want it to work like the other one. It's like, we'll just use the other one.

That's, That's your simple answer. The main difference, I guess it goes back to that idea of the children having influence or not. So like, if you need. Each column in each row to be sort of independent from one another. So like when you do a display flex on the navigation, like it doesn't matter how big each word is.

Like each column is the size of the word itself in the navigation. So like home is going to be shorter than documentation and that's good. Right. And cause you get consistent spacing and everything. Whereas if I tried doing that with grid, I could actually force it and I could get there, but ~it. ~[00:27:00] I'm putting in maybe like five lines of code or less than that.

I'm sort of like fighting instead of just display flex and it works, I need to add in extra lines of declaration and I'm going against just the way that it wanted to work in the first place. So it's, I think that's like the way, the general way I look at it is like, which one is going to let me do it with the least amount of code now, part of that.

Also means you need to have experience with using both of them sometimes to know that because it's like you might not know that so if,~ if~ you're not familiar with either one, you're like, Kevin, you're not helping me right now. Um, but yeah, if, each item needs to have its own size, then Flexbox is probably better.

Whereas if you just need something that's a bit more consistent, if you need more of a grid then grid is better or you need your columns might be different sizes, but the item on the next row has to match the item above it. Then grid is going to be better. Whereas if everything can just be independent from one another, regardless of where it is, then flex box is the better option.

Yeah. I found that just even as a simple exercise, it's like taking some little toy [00:28:00] problem or a little toilet you're trying to make and like, okay, I'll make this both ways. Then you can walk away and be like, I understand this better. Like I understand why I would, should use this for this.

And then it kind of like most things I feel in CSS, you kind of get this soft understanding and you have an intuition just looking at something like I should probably use. One or the other for this and it becomes less tricky, but it is hard to like know going in if you're totally naive to both of them, 

I really liked that idea of building it with both. ~I think that's,~ I think that's a really good suggestion for people that ~are at that,~ you've gotten the basics of them both down and now I'm just trying to understand which one to use when I think that's a really good idea.

Yeah. Yeah. And it can be hard. People are just like trying to make stuff and get it working. So I understand. I know Flexwell is like, you can probably make it work and do your thing or the opposite. And that makes sense too. But yeah, just got to get in and play with stuff.

Is there anything else any specific like practices in this vein before you wrap here? You would recommend people check out or undertake to help them maybe struggle less with CSS when they have to write it?

Yeah my common suggestion is always just build [00:29:00] more stuff right practice makes perfect, but I think practicing on smaller things is awesome. I know, especially mean, there's so much new stuff coming to CSS and I'm always asked, like, how do you keep up with it? And I'm in a privileged place where I can just do it all day long, which is great.

I realize a lot of people like this is your job, you're working full time or you're studying on the side and you have another job, so it's a little bit harder, but like building out small little things. There's. Websites like FreeCodeCamp ~FreeCodeCamp has stuff, but I'm thinking, sorry, of ~Frontend Mentor that has like little projects.

There's like full page builds. You don't need to do those necessarily. Just take the small ones that you could build in like a smaller amount of time. Uh, There's another site now called iCodeThis, which is like daily UI challenges. Just look up daily UI challenges and find stuff or find you see a cool component on a page, just try and build it and see what it's like.

I think. One of the best things to do is don't look for things that look really challenging. Look for things that look like, oh, that's not too bad. Cause you'll probably end up finding something in that not too bad thing that is a challenge.

Yeah. Whereas if the whole thing looks like it's going to be hard and you don't know how you're going to do it from the beginning, it's just going to [00:30:00] be a frustrating experience.

Whereas. If you sit down to like create something and it looks really simple and you can just do it you know that makes you feel better about yourself But you'll probably run into one or two things along the way where it's like, oh, maybe I need to learn this extra little thing here How would I actually do that?

I didn't notice that when I first looked at the design and you sort of gain little things here or there So just spending like a small amount of time on stuff can I think go a really long way

Good advice. Is there anything else you'd like to~ leave listeners with or~ point listeners to?

If CSS is something that you struggle with my YouTube channel is, I have way too many videos there now I'm over 700 videos and they're mostly all based on CSS. That'd probably be the main place that I would point people towards whether it's about just general stuff like this or specific problems, I try and tackle both as much as possible, but a lot more lately, it's been like general.

Approach to make things easier. It's sort of my focus now. And otherwise from there you can find links to other stuff I'm up to, whether it's my website, my newsletter and other things like that.

Cool. Awesome. ~Thank you.~ Thank you so [00:31:00] much for coming online and chatting with me about styling. Kevin. It's been a pleasure.

Yeah, it was great. I always, I'm always happy to talk about CSS. So thank you so much. I really enjoyed that.