Should We Stop Teaching Width and Height to CSS Beginners?

Key Takeaways

Hello, my front-end friends, and welcome to my podcast, General Musings. My name is Kevin, and in this podcast, I talk about whatever is front of mind for me in any given week, usually in some way that's related to front-end development. And this week, we're staying very much on topic because we're going to be talking specifically about CSS. Recently, someone over in my Discord community, which is linked down in the show notes, if you're interested in hanging out with other front-end developers and getting help with your front end and sometimes backend problems, some people, there's a few backend devs in there as well. Uh yeah, this person was asking about a sane way to start a project because they were feeling frustrated, which I think we can all relate to at times uh ws specifically. And uh they felt that a lot of the user agent styles were actually getting in their way and they were having responsive issues and other things. and they asked if it would be a good idea to do the star selector with an onset all on it, which thankfully before I saw the thread, a few other people had got there first to quickly reply and say, "Please don't do that cuz it's a really bad idea." And it made me start thinking a little bit about this where it's a topic I do bring up from time to time because I see a lot of people don't appreciate the default behaviors that we have. And I think it's really important to think or not to think of but to to see the defaults that come with the browser as a mostly sane starting point. And I mean, for example, most elements are block elements. And if we did an onset all with the star selector, it would throw all of that in the garbage. Like everything becomes inline because inline is what something is before the user agent style comes to say no, this should actually be block, which is kind of interesting. You often don't realize that unless you do a onset all on things. And you probably don't want to be going and having to declare display block on most things. uh since we'd probably want that as the default on the elements that already have it. But beyond that, even like talking about inline and block elements, they have default behaviors themselves, right? Like not things that are coming even from the user agent styles because they have both a width and a height of auto on them, but the width and the height of auto works differently for the two of them. So like the auto behaviors and these defaults that are on these elements are specific to how they work and we don't always appreciate how good those auto or default behaviors actually are. The things we do talk about a lot like say with a block level element we talk about how when you create block level elements they always create a line break stacking one on top of one another. And that's obviously a handy thing and a good thing to know. And once you understand that you're okay. These will always stack and then we often learn about the box model at the same time, right? We can set a width and a height, our margins, our borders. But what isn't really talked about is what I was just talking about is like those auto things like what is happening and I I guess to a certain extent it is you hear well okay it it's taking up all the size. Sometimes you'll see like oh put a background color on there and you can see that it's actually big even if you only have one word in your paragraph for example. But we sort of gloss over a lot of how though that part of it works cuz you're like, "Oh, it is this big and it only is as high as the content." But then we can apply a width and a height and you make your box and your text fits in your box cuz you're doing very beginner stuff. And at that stage it makes sense to sort of understand things in that way. But I don't think there's enough emphasis that's put on to what's happening before we put a width and a height because these days like are you really declaring a width and a height that often? And we have to learn that these properties exist. I get it. Which makes me wonder, do we need to teach beginners like super early on, should you really be learning about width and height? I recently put out a new course on like HTML and CSS for absolute beginners and I probably did. Um I'm assuming I did. And I've been changing a little bit about how I've been teaching things lately. Like the order that I teach things in to we always I find like all the paths for learning especially the beginner material follow a very similar order. And I've been trying to think about like what would be the more useful order to learn things in. Like I'll teach grid now before flexbox. That's the big one. I also teach positioning much later on than most people do because I feel like positioning is like you should understand layout with flexbox and grid before you worry about positioning because that's sort of like the bonus like okay now I need to make these tweaks. Bonus isn't the right word but it's about like tweaking what you're already controlling with the other layout methods you're using. Cuz I'm sure I don't know if you're like me but when I learned about position absolute I was like gh why am I bothering with all this other stuff? I can just tell stuff where to go. uh and then everything just falls apart. It's like the most fragile way to build anything and that was even before we had like I was doing this with static websites and it was still fragile. So like these days with responsive things it's even more fragile and and would be really hard to create something that way and yeah I I had an outline that I've been following for this and I've completely gone off track thinking about this width and height thing of like should we teach people width and height early on? We need to I think it's important to learn the box model and they have the content. I actually am curious now because we used to need width and height well width anyway to make layouts like when we're going back to what I was saying like static layouts and then we had the floatbased layouts um where you had to declare widths on things to be able to make a float-based layout. With grid and flexbox these days you don't need to. It comes in handy. It's important to do. I almost feel like you could get around to those a lot later on. Like margin padding borders 100%. Learn that at the beginning, but like say you do margin padding borders and then you learn you can make a box, but the boxes are still stacking. So then you have to add either flexbox or grid to actually make things go next to each other and then you're not using the width again. I almost feel like width should be something that's taught later on. Hm, that's interesting. I'm not about to redo that cord. Ooh, should I? Hm. We'll see. I don't know. I'm very curious about that. Now, I think that can be brought into like later things because of how width I find. Okay, I'm way off topic and I'm I'm on a this isn't what I was planning on, but width is more useful than height in general. It's something that will be declared more often, but like within the flexbox context, it has certain things that are important. Within grid, you're not going to be using widths too often. The default behavior there works well. Well, we're going to circle back to those defaults in a second. And what I was the whole point I was making with this, but the defaults make more sense there, right? Because they are that just takes up the size of its cell. And like I guess you could use a percentage to be like I don't want you to take up the whole size. Um I'm trying to think and like I guess icon sizing and other things like once you get outside of layout specifically and you're like, "Oh, I need this icon to be a specific size." Then you're actually setting just a width and a height on it. So, I guess it depends on the context a little bit there as well where sometimes you just have those fixed sizes, but I feel like again that's something that could come in a little bit later. Images have the responsive issue, but that's where we can just set a min width of 100%. Uh, max width, max width of 100%. And we're we're good to go on those. I almost feel like you don't need to cover width and height early and it leads to very beginners having bad habits is where my thought process of this is going. This circles back to what I was actually just thinking about because I think in my big thing is we want to embrace what the default behaviors are. That was sort of my outline of this podcast originally where the default on a block element is to be the full width and the height is to be as small as possible. Right? to 100%. Well, it's auto. It's not quite the same as 100%, but it's taking up the full width of its parent and zero high. As the parent gets bigger or smaller, the child that's a block element will match that. And that could be as the viewport gets smaller, everything's getting smaller. So eventually that child's also following along with that. And then as that's getting narrower, the content inside of there is growing because the text lines are wrapping and other things. So the content is getting taller, taking up more vertical space, and so the element is growing in height to do that automatically. It wants to be zero pixels tall, but it adapts to the content and grows to match the content that's inside of it. And within most of the context that we create layouts with anyway, so that's there's that distinguished thing, right, with thinking about layout versus like the small little components or something. But even then, like if you have a tag, you don't want to set a width and a height on a tag. And I see people do this all the time. you have a button and they set a width and a height. I the amount of times I've seen a button with a height on it and then they're using flexbox to center the text in it. I'm just like just put a little bit of padding top and bottom, please. And you're going to get the exact same thing, but it's just so much more robust cuz if you set a height on it and then you change the font size now you need a new height on it, right? And these are all things that we all learn over time. Like I remember back in the day with navigations or headers and stuff um because it used to be this is before flexbox it's hard to center things vertically and so you do that you'd set a height and then you would set you know try and play with it and magic number your way there and then the trick that you'd learn is that you could set a height and then set the line height of the text inside of that to match the height of the element and then it would actually center the thing if I'm remembering right. Hopefully that's what the trick was. I know there's a line height trick to set vertically centering, but then of course if you ran out of room a little bit and then the text wrapped, you just have these huge line gaps. So you're like, "Ah, that's not the right way to do it." The right way to do it is just use some padding and get it to the rough height that you need. And yeah, I feel like the if we avoided teaching people in the very early days, like you can day two, you get CSS, you get around to saying, "Oh, by the way, you can set a height, but have you noticed we never had to do that until now?" Um, so like there's specific times and I think we could put a lot more emphasis on the default behaviors and the way they're working and then leaning into those defaults, right? So setting if you need if your content's getting too wide as the viewport's getting bigger and bigger and you're on an ultra wide, you don't want to have to like move your head across to be able to read the text. So well, we're working with those default behaviors. It wants to be as wide as possible. So then we can set a maximum width or if you want to use the logical property a maximum inline size and then stop it. I'm going to not mention it's easier for me to talk out loud with width and height. But if I was writing the CSS, let's just assume I was using inline size for width and block size for height, which if you don't know, those are the logical properties to go with those two. Uh but yeah, right. So my my content is getting wider and wider and I want to allow it to shrink when the viewport's getting smaller cuz that's a good behavior. I want to lean into that default and I just want to set the constraint of a maximum width to prevent it from getting too wide. The same way I would take that approach on height, but height, I have to think about it. The auto is the opposite. It wants to be as small as possible. That's a good behavior to have. That works well for me. If it wanted to be as tall as possible, I don't I don't think we could make websites, right? Everything would just fill up the viewport and it would not work. We want it to be as short as possible, but to adapt to the content that's fitting in there. But maybe it's too short in some situations. I need it to take up the full viewport. But if I have lots of content, maybe because my viewport got narrower or I just added more content to there, I don't want that content overflow. I do want to allow it to grow if it has to. So I work with how the browser wants to work. And I set a constraint on it saying I'm going to set a minimum height. And then if it needs more room, it is allowed to grow. And like that means we have responsive things. Well, I mean if I didn't even set those constraints, we have responsive things. Everything just works. But we lean into and keep that responsiveness by setting the constraints on it instead of trying to force matters and and do what we want to do. And I think we would solve so many people's and beginners problems if we didn't teach width and height. I'm like convincing myself more and more as we go through this. Let's stop telling people early on like first week of learning CSS, you're you don't know that width and height exist. We show them min or max versions of them, but we don't tell them the the actual property, right? And then they surprise them later on uh once they've built up the good habits, then work with uh a lot of just how things are working. And I think that would just really help reinforce things and also make them realize we don't need to set these things cuz it's intuitive to want to set a width and a height on something. I see a design I'm trying to match. I'm going to make it that size and then I'm going to get the content to be in there. That's how I would do it with a design software. So why wouldn't I do it in in the CSS, right? And it's because that's a bad idea. But then we have to learn why that's a bad idea and we have to unlearn those bad habits that we've built up where we just could just not teach it that way in the first place. But I guess so yeah, if you have a friend or something that's learning it, don't tell them about them, I guess, is where I'm getting to with all of this. But or if you're in a boot camp right now, you're an instructor at a boot camp, maybe there's five people listening that are in that situation, but just something to think about a little bit. um where yeah I know you don't in the boot camps you don't spend a lot of time talking about CSS so like just don't mention width and height simple again max min those are fine don't mention the the fixed ones um because even width is a percentage these days how often do we really need width as a percentage these days trying to think times I'm using it again it's more about like sizing small icons and other things and width percentages I don't use for sizing stuff very much we have all these other context textual units that are much more useful. Um, I'm trying to think. I can't think of any specific use cases. I guarantee you I do use percentage at times, but it it's one of those more niche units now uh with with the types of things that we're building compared to what it used to be. Um, even I guess I have used it with like a grid template columns and stuff, but then now we're getting way beyond setting widths in in doing that. And we're setting there you're actually setting a width in a different way anyway, right? and you're just setting like this is the the column size and then the element will just fill that space up. So it's exact that's sort of how we create layouts now anyway isn't by saying widths and heights on things. It's about setting up the layout and making things fill in those spaces that we've created or we're going the flexbox route which is more based on the intrinsic size of things anyway that's less based on the size of the element itself um or well the element is sizing itself and each one is kind of independent type of thing. You know what I mean, right? And uh wow, this I got a lot more complicated and on a little rant there than what I wanted to, but I guess the main thing is we can't tell the browser or we shouldn't be trying to tell the browser exactly what we want it to do. Uh whether that's, you know, working with a fixed size or whatever. And I'm saying this in the context of width and height. I'm sort of stuck on that a little bit because of this mini revelation that I've had about teaching that. But I think it applies to like everything we do when it comes to CSS where we always want to be conscious of what's already on place like what's happening now on before I write a line of code. Uh, so this could be a width even, again I'm bringing up width, but I was thinking like another mistake I see a lot of people do is a width 100 VW on the body because they want the body to be full size, but it was already doing that. It was already filling up that space. And 100 VW actually now will go underneath the scroll bar on Windows and anytime there's a fixed scroll bar and then that causes horizontal scrolling. And there's all these problems that come from setting or declaring things that we didn't need to declare or we just, you know, to go into other properties. We or not we but a lot of people overdeclare things that could be inherited, right? I see declarations for font family over and over and over again when it could just all be placed on the body because it's the same font family being applied everywhere and then you want to change your font family. Oh well, I guess you know we can do a control find replace type thing, replace all the font families, but I could have done that one time on the body and that would have been a little bit easier and it's a lot easier to maintain and you don't have to worry about forgetting it in one place or another. Uh, and those like we don't need to do that. So, we shouldn't do that, I guess, is is the main thing there. We should only declare something if we have it not by explaining why we're doing it, but by looking at the screen with what we currently have and saying, "Okay, I need this thing to be different from what it currently is right now." If that makes sense. All right. So if I look at it and go the font family is currently wrong and I'm going to change it rather than just having a full screen VS code without looking at my browser and just writing in all the CSS that I need which just lends itself to writing a whole bunch of CSS that you don't actually need cuz those things are already in place and less maintainable code a lot more stuff going on for no reason. Um, yeah, it just becomes a little bit of a nightmare. And I find that's one of again another thing that a lot of people do and I see a lot of and it's one of the things I help people fix a lot of the time is that type of over declaration on things that they never needed in the first place. So yeah, I I'm going to link to a survey and the survey I had planned to link to this anyway and it was going to be a one question survey. It's now going to be a two question survey because I want your opinions on whether or not uh my idea on not teaching within height is a good thing or not. And uh so the first question will be that and it'll be just a yes no you check box I don't know it'll be something a yes no question you just click on the one that you want maybe radio buttons or whatever uh and you can hit submit on that one and the second question is because I want to know more about you and who you are so it's a one question thing as well uh just about what the listeners of this uh I want I have an idea of who my viewership is cuz I think it's going to be a little bit different from my main channel. I don't have a great handle on that either to be honest. Um, but I have my regular newsletter. I'm sure some people that are listening to this are also newsletter subscribers. Uh, but I'm just trying to gauge what audiences are listening to which of my content right now to know more of what I should be talking about across my main channel is CSS tutorials. It's what it is. This one is sort of CSS tutorial, but it's a talking head one. Um, but I want to know like should I focus more on this type of content or should I be focused more on some of the other things that I've talked about here? Uh, do I do more interviews? Is it more Anyway, I'm trying to figure out the type of content I want to do specifically on this channel. And so there'll be one question. So the whole thing should take you like 10 seconds to do once you click the link. That's my goal for it. So just click answer the yes no question. The other one will be like a select menu. you can just or multiple choice probably where you can choose multiple things. I think that will be what it is. Um just so I get a better idea of the type of content I should be delivering to you and and who's listening to this cuz this channel is actually growing in size right now. It's starting to gain a little bit of momentum. So I guess I'm already doing the right thing, but my topics are all over the place and maybe that's what people want. And I'm also going to continue just talking about whatever is front of mind for me in any given week. But if I can shape what that thing that's front of mind for me in any given week is or give it a little bit of direction, um, I'd probably more often than not steer it that way, but there will be divergences and and wiggles and other things and all of that from time to time as well. So, uh, because I do want to keep it pretty casual here, uh, pretty relaxed, pretty low-key compared to my other things. not, you know, I'm not doing any on-screen graphics or like as I was going through all of this, I was thinking like, oh, it'd be cool to have like the on-screen graphics showing some of the things I'm talking about. That's not what this channel's about. I'm not going to I just don't have the time to do it, to be honest. Um, but, um, yeah, we're keeping this channel low-key. Uh, but having a little bit of direction to it would probably be a good thing. Um, it already has some, I guess. I just want to know more about you, I guess. I don't know. I'm rambling now. Usually when I hit this rambling stage, it tells me that it's time just to wrap things up. So, I'm going to wrap things up, say thank you so much for listening, and of course, until next time, don't forget to make your corner of the internet just a little bit more awesome. And please go down to that link and take the survey. I would really appreciate it. Thank you very much. Five.