Transcript
Speaker: Hello my friend and friends and welcome to my podcast General Musings. My name is Kevin and this podcast is the audio version of my weekly Sunday newsletter where I talk about whatever is front of mind for me in any given week, usually in some way that is related to front -end development as well as share interesting sites and resources that I've come across in the last week as well as share what I've been up to in the week as well.
Speaker: This week, I'm going to be talking a lot about CSS length units because one of the complaints I hear about CSS is the number of length units that we have with a total of 54. Not all of them are supported though yet, but we still have 54 in the spec. And yeah, that is a lot of units. But to me, this is actually a feature and not a bug.
Speaker: First of all, about half of the units that we have are various versions of viewport units, and half of that half of the units are the regular width and height versions, with the other half being their logical counterparts. So we have inline size and block size, for example like VW for viewport width, and we also have VI for viewport inline, or I guess viewport inline size.
Speaker: And the other thing is that they keep adding new units. Like we have a new cap unit and an LH unit for cap height and line height. And we have these because there are use cases for them. The new line height unit is great for creating vertical rhythm, which has always been a really tricky thing to do with CSS. And Adam Argyle recently highlighted this with a code pen example that I'll put a link to in the description slash show notes.
Speaker: We also have things like the CH and X units, and a handful of other really handy ones that you probably will only use in really specific use cases. We basically have the big four, right? We have pixels, M, REM, and percentage that we'll use like, what, 98, 99 % of the time, and then the other units that they turn out to be really useful, but for really niche use cases.
Speaker: Now I get it, it sounds like it would be nice to have just one unit that could rule them all, right? We could rely on that for everything, but that's until you start to think about all the different ways that we use our units. Pixels are fine for like your box shadow or adding padding on something if you need to and you wanna use pixels for it, but then M serves a really good purpose or having a percentage on a width can be super useful. There's times where we need to have different things. And then we start getting into those more niche use cases that I keep talking about.
Speaker: with, say, the X as an example, and in case you haven't heard of it, the X unit matches the X height of a font, which is basically the height of the lowercase letters. So let's say you have a decorational suit element and you need that to be the same height as your lowercase letters, or maybe you have something like a small tag and you want the text inside of that to be the same height as the lowercase letters of your regular text. You basically have two choices here. You can magic number your way there with M's, or even pixels, I guess,
Speaker: or you could just say font size 1x and you're done. And that's also not to mention that if you went to the M root and then you change the font family you're using, you'll have to magic number it all over again because you'd think that the M's would match but X heights are different with every font so it would just sort of fall apart and you'd just have to be stuck there trying to do it again and that's really annoying.
Speaker: So I don't know about you, maybe you don't mind magic numbering things, but for me, the second option of putting a 1x on there, it just seems so much better. And the same goes for most of the units that we have. You don't need to go and memorize them all either, but it's good to know there are a bunch of units out there that are relative to different parts of a font's height, and then you can just google them when you run into situations where you think one of them might be useful.
Speaker: Now from my own experience of talking with people, most of the people who complain about this type of thing are people who don't write a ton of CSS. They spend most of their time working on backend stuff or writing JavaScript, and then they get stuck having to write a bit of CSS every now and then. And in those situations, I don't blame them for getting frustrated because then all of a sudden you're thrown into a situation where you have a ton of different options that are thrown at you when you feel like, why do I need all of these? I'm just trying to set a font size or something like that.
Speaker: So of course you feel like just having one thing would be a lot simpler, but no one solution could fill all of the use cases that we have. I mean, we could look at JavaScript also here where we went from having one way to create variables with the var to now actually having four ways to do it. And there were problems with var in the way var worked and people were a bit annoyed with it, so they fixed them by giving us two new options with the let and const keywords.
Speaker: And, you know, that was awesome. Each one of those was an improvement over var, but it still became two different ways to do something when we only had one way to do it before. And I guess at that point it was three ways because of course we still had var. And now they're also adding another one with the using keyword because they realize that as good as let and const were, there's some niche use cases where another option would be useful.
Speaker: And of course here, once again, we're running into this world where most of the use cases for using are more of a niche use case. You definitely won't be using it nearly as much as you're using the other two, but using has its use cases and you'll be happy to have it when you're in the right situation. A little bit like with X and LH units in CSS. And of course, everything goes through this, right? We find the limitations of existing solutions, so we come up with new and improved ways to solve those problems.
Speaker: So, here's to looking forward to the next batch of units that we get, because the more we have, as far as I'm concerned, the better. Plus, figuring out how new units like LH and X works is a lot simpler than figuring out how using works, at least for someone who writes CSS all day long anyway.
Speaker: But speaking of units, actually, one of the reasons this was front of mind for me this week is I actually made a flow chart to help people pick the right unit, depending on what their situation was or what their need was. And if you want to find it, you can actually just go to what unit dot com. And I also made a video where I was going through a bit of my thought process of like, you know, why did I have these decisions through that flow chart? Just to give it all a little bit of context.
Speaker: And actually the main purpose of the flowchart isn't to go into all of the niche use cases either, but more about helping people steer away from the problematic things that I tend to see people doing, like the overuse of viewport units and a few other things. And actually most of the branches actually end up at some combination of pixels, rems, ems, or percentages, which are those big four that I mentioned a little bit earlier.
Speaker: Now switching gears a little bit as we head into the other awesome stuff from around the web section, we'll dive into the world of accessibility, though in a way, accessibility has some similarities to what we've been talking about so far because a lot of people struggle to keep up with the best practices of accessibility.
Speaker: And, actually on that matter, one of the questions I actually get asked a lot about is testing with screen readers, and Sarah Suidane has recently put out a very in -depth article that explores how you can get set up to test sites and projects using one.
Speaker: The article also links to a lot of other resources like helpful guides and cheat sheets for using them. So if it's something that you've ever thought about and maybe you've been hesitant to or you've had trouble setting one up, I'd really suggest checking out her article. And speaking of Sarah and accessibility, I have mentioned this a little while ago, but since we're talking about this, I figured if you are interested in accessibility, Sarah also has a fantastic and really in -depth course on accessibility that I highly recommend.
Speaker: And that is it for this week. Depending on how you're consuming this, if you prefer a podcast version of it, a video version of it, or a written version of it, there are links to all of those in the description slash show notes, as well as links to everything else that I've mentioned along the way as well. Thank you so much for listening, and until next time, don't forget to make your corner of the internet just a little bit more awesome.
