 Hello, my friend and friends. I've made a few videos recently looking at a whole bunch of the different CSS units and I even made a flowchart to help people pick what CSS unit they should be using in any given situation because we have 54 different length units. Yes, 54 of them. That is a lot of units. And with all of them being very front of mind for me, especially after spending so much time on that flowchart, I figured why not rank them. So here we are. Let's dive in and rank the CSS units. You can see here we're going to, you know how these things work, right? I'm sure you've seen them, but A to F, the same way a school system works. And if anything is better than an A, then it gets an S for being above the rest. I guess it's the top ones you can get. And as you can see there, let's zoom out a little bit and zoom back in. We're going to start with our absolute units, which are those ones that are right there, which are mostly for print. But we do have pixels that are in there as well. And so we will get around to those in a second. But I guess we should look at the print ones first. And just as we dive into this actually, I just want to say a really big thank you to Ali Fahim for suggesting I even do this when I shared the early version of my flowchart on Twitter or X or whatever we want to call it. He suggested I do this. So thank you very much, Ali. I think this is going to be fun. And, you know, let me know what I get wrong in the comments as usual with all of these. And I'm just going to select all of these ones because they're print. I almost need like an on categorized for print units. You know, because if you're doing print related stuff, I guess they go here. And if you're not doing print related stuff, they go here. So I'm going to put them as F because I don't really do print stuff. I know people ask me for print stuff. And it's really not my world, which is funny because I used to do print design. But yeah, the only thing I will say here is I'm going to move the Q unit up to here because Q is quirky and different. And it's a good trivia question. So it gets bonus marks. The Q is like, you know, it's the only capital one. It's nobody knows it exists. And if you just see if you don't know, it's like a really, really, really, really small number. I forget what it's like one tenth of a millimeter or something ridiculous. I don't know exactly, but it's super, super small. Yeah, so we'll give it bonus points for being kind of quirky and different. I know a few people have told me, actually, they have used this when they need that little difference on something. So they've used the Q in those situations. And actually, we're getting the pixels now, it's based on like the pixel ratios and everything that the device has to sort of figure it out. But it's 196th of an inch, I'm pretty sure is a CSS pixel. It's not a screen pixel. And I'm giving it a C. Maybe, I don't know, it's almost like it's a C plus, let's say. And the reason I want to give it a C plus type of thing is this because they're super handy, they work well for when we need them, you need a border, you're going to use a pixel, you need a box shadow, I guess pixels are okay. You need for certain stuff, there's no problem with them. But people overuse them. They're used for font sizes all the time, which can cause problems from an accessibility point of view. And sometimes people just over rely on pixels when there's better units out there. So it loses marks for that. So I'm going to sort of give it a C plus. I'm happy we have them. But it sort of sucks that everybody relies on them too much. And yeah, that's what I think. I know some of you would definitely probably give it an S tier and others might even give it an F. So maybe I'm a little middle of the road, but we'll find some that we can cause some other arguments on. And again, these print ones, they're not really Fs, right? They're just putting them there because I'm not doing print related stuff. So, but yeah, let's move on to the relative units. We have a lot of relative units, some of these you've probably never seen and some of these you definitely know. So we're going to start, I guess we'll start with percentages because everybody knows percentages. And I'm going to give it a B. I think percentages do not get an A just because I love percentages. They're awesome. They can do lots of really cool stuff. You know, it just works well. But then they cause some problems too, right? They're awkward if you want to use them as a height. They're, if you do it as a padding or margin top and bottom, it's just really wonky and probably doesn't do what you want it to do. They're just weird stuff that happens with percentages. When they work and they do what you want them to, they're awesome. So I'm super happy we have them. So they're going to go here. Even I'm just thinking like we have grid also, right? If you're using percentages within grid, you probably don't want you because that's where overflows happen because it doesn't take into account gaps and all of that. So I'm going to stick with the B just because when they do what you want them to do and they're super handy and I like having them. So I'm happy they're there. M, do M's get an A or a B? I'm going to give M's a B because once again, they're super handy. I'm super happy we have them. But they just leave that possibility for some chaos, right? Whereas if you have like, if you do it on purpose and you do it well, where you can actually like have all of your font sizes set with M's, I've seen some people that really love doing that. But one little mistakes and work and it just caused chaos to happen where you get the cascading thing of M's being based on M's being based on M's, and then your font size is six times bigger than you thought it would be. So just because of that, I'm going to give it a B. I'm so torn because I use them for so many things. Maybe it's a B plus just because I like it a little bit more than percent. Do I like it more than percentages? I'm not sure. I'm going to stick with B. We have a lot of units to get through. I can't overthink this. X is going to also get a B. Okay, we're going to X, L, H, I see. I'm trying to remember what I see is. We'll leave I see here for a second. It might be the one that's for vertical text. I might have to even double check that cap is going to come over here. These ones, this goes over here. Oh man. Okay. So this is part of that can go here. Okay. So X, L, H, and cap, and then we have Rex, Rick, and Ick. I should have said the RCH goes here. I was looking for the relative ones. Oh, this one. We have the X, the L, H, and the cap, and these ones are all, so this is like the cap height, the X height, the line height. I'm leaning towards B because they're cool, but they have very limited use cases. You generally would be doing this on like a span or a pseudo element because like I could see doing an X on a pseudo element for like a decorative element that needs to be the height of my lowercase letters, which is X is the height of a lowercase X, cap is the height of your capital letters, and L, H is the line height. So it matches the height of your line height. They're very niche, but when you need them, and the browser supports I think X has good browser support and these two, it's not there yet, but I'm not going to talk about browser support. I just want to talk about the usefulness of these units. Man, do I give them Bs? Just because like they do what you expect them to do, and I don't see anybody misusing them, I am going to give them a B. Then that leaves me with rex, this one, R, L, H, and the R cap. I'm giving these a C because I don't see when I'd want to use them. I'm sure there's times. Do I even give them a D? So these are all the same thing, but it's based on the root rather than being based on the element that you're declaring. So if you had a span, that's where I said like a span where like your smaller text is the height of your X height. I could see being something being useful. I think I've done something like that. The LH1, it's not as often, but like these are all things where I want it based on the font size of my element that I'm putting it on. I don't know why I'd want the root ones, and I'm sure if you have a good use case for these, leave them in the comments. I haven't figured them out. I also haven't used them, to be honest with you. I've never used any of these three. I'm going to give them D. I just don't see when I would use them. And maybe there's better use cases. And if you have one, and then it could get graduated up to a C, I just I have no idea when I'd actually want to use one of them. They don't cause problems. They would do what you want them to do. I just don't see the practicality of them. But maybe I'm just not thinking inside the box enough. A small little interruption here, because as I was editing this, I said, Kevin, what were you thinking, putting the relative line height there? It's actually incredibly useful. And I probably should have given it an A. I'll put a link to a resource that Adam Argyle shared down in the description. But the RLH, or the root line height, is really good at setting consistent rhythm within a website. So if you're someone who's done typography and other stuff like that, and you've always been driven a little bit nuts by the lack of consistent rhythm setting on a website that you definitely could easily do with a print document, the root line height might be the solution that you've been looking for. There's other two. I'm still not sure exactly on when I would use them. But the RLH on revision would get an A very easily, just because it solves something that's been really hard to do in CSS until now. But let's go back to the list now. CH is going to be my first A. And I'm very tempted to give it an S. Is CH going to be an S here? Or an A? We're going to put it here, and we're going to revise at the very end and just make some last-minute adjustments if we need to. But I'll put CH there. I'm very tempted. Okay, so CH, if you don't know, is the character width sort of. If you come from a print world, it's actually what an M roughly would be. I think it's slightly different because it's based on the number zero rather than the width of a capital letter M. And it's weird that we have M's in CSS that are different from M's in typography. But anyway, CH is roughly the width of the zero character. And why this is useful is, again, you wouldn't really misuse this, but setting a max width on things like a paragraph or a heading and using CH is just Chef's kiss. In typography, what max line lengths CH makes it really easy to do that. And then we have the root CH, which again, I don't know why I'd want a root CH because I want it to be based on that unit or like where I'm declaring it. I don't want my headings to be based on 16 pixels, which is probably what my root is, or well, I guess it's a little different because it's CH. But like, for my headings, why would I care what the CH is on my root? Like, why would I use that? So once again, these ones probably use cases, but I don't know what they are. So I didn't want to get this wrong because I've never used it. The IC unit is indeed for, I'm just going to lose it there. Here it is equal to the advanced measure of this glyph. This water ideograph found in the font and used to render. So again, this is dealing with vertical. And I guess it's a little bit like CH equal to the advanced measure. I'm not sure what advanced measure is. Yeah, it's like CH, but this way instead. Perfect. So just I wouldn't use it. But I'm going to group it with the CH because of that. And I'm going to group this with this RCH because of that. And I don't really have any other information on it. So I'm guessing it would be useful if you're working with vertical fonts. I don't know. Do I give it a B just because I don't know. I'll leave it here. Yeah. Again, sort of falls into like, I don't use, maybe we'll do it like on this side, because I don't use it. And we'll throw it over here, just because I don't have enough information. And now we have the REM and REM. REM would definitely be a tier, right? REMs we use for so much stuff. They're super useful. It's the one time having it based on a base thing makes sense. So you have all of your font sizes based on the root. You could always change the font size of your root. Just don't use pixels to do that. But you could change the font size of your root. And then all of your fonts can adapt to that if that's the way you want to handle responsive typography. There's other reasons REM is good, but it just gives us a nice consistent base to work from without the side effects of pixels, basically. And so they're perfect for a lot of use cases and so much stuff. So definitely a tier. I use REMs everywhere. I have no complaints about them. I guess being base 16, just because browsers tend to be that as a default can be a little bit wonky and people like to complain about that. But I don't care. It's getting an A for me. Next up is, oh my goodness, I don't have enough room in my chart. Our viewport units, which is half of our units, I think. My chart's going to die. But we're going to sort of group these off a little bit. And you might be surprised here because I'm not a huge fan of viewport units. I'm giving these two Fs. Viewport widths, people just abuse the crap out of them. It causes overflow issues. I see people put 100 viewport width on their body all the time. It causes overflow on browsers that have fixed scrollbars that Chrome on Windows, which is lots of people, it does nothing because your viewports are already the width you want it to be or your body. People use it everywhere. They shouldn't use it. And it just this is like beginner mistake is using viewport units where you don't want them to. They probably don't do it. You should. People use them on font sizes and it makes their fonts unresponsive and causes or makes them responsive, but makes them inaccessible because you can't zoom in and out. So it doesn't work. And then viewport height, like slightly better, but it's still like an F. It can be handy as like a max height, I guess. Again, viewport units can have the right thing, but they just cause too many problems. And everybody likes complaining about viewport height on mobile. It doesn't do what you're hoping it will. So I'm giving it an F. I don't care. They go there. VI and VB are the same thing, but they'll get these just they'll get like F pluses just because they're the same. So viewport inline and viewport block. So it's like the logical property version of them. So just because they're the logical property version will give them like a plus on top for being logical. Which isn't how it works. But V min and V max, I'm going to give like a C minus. They're sort of awkward to use, but when you get them to work right, they're cool in a way, right? They're kind of funky. They're kind of weird. They're kind of quirky. But they sort of they can be handy. So yeah, I mean, I'm going to go with like a low C. I don't know. They have some of the trade offs here. You're not going to use a V min and V max the same way you probably would use those. Go with the C just because they sort of yeah, whatever. That's where they're going. Then we have the next batch, small viewport, large viewport, dynamic viewport, large viewport. I'm going to put down here just because as far as I'm concerned, it's the same as VW. So I don't know the difference. Well, generally they work exactly the same. I know this is the viewport. This tends to always be the same thing as that though. Maybe there's some edge cases where there is a difference between the two. But I don't know. Small viewport width gets bonus points. I know small viewport width. I don't know. What am I talking about all of these? I'm going to overlap because we're going to run out of room. The VWs of these don't change anything. Right. As far as I know, the scroll bars not incorporated into the dynamic or the small. So it doesn't change anything with scroll bars. And I don't know any devices that have the UI elements vertically. So if there's ever use cases for those, I don't know what they are. Small. Yeah. So LVH is going to come here. I was thinking with the VH before when I was saying that it's the same. VH and LVH as far as I know always function the same way. So I'm going to group them together. Again, maybe there's something different. DVH gets a D for trying hard. That's usually how that works, isn't it? You get a D because you tried, but it's not good enough. Just because it gives you that jumping content. And then you have to repaint the page because your area grew. And if it was a nice smooth transition, I'd give it more points. But you scroll, you let go, it jumps. It's annoying. And SVH will give a C just because it's sort of what you want. It's more practical than the regular viewport height. It fixes a lot of the problems. It doesn't take into account the keyboard and stuff, but at least we have it. So it tried hard and it's a little bit better than the DVH. So it gets a C. Then it's just more viewport units. They never end. I guess like here, we're just going to small inline. Inline is left to right. That's the same as width. So that gets grouped here. I don't care that they're logical. It's again, small viewport inline, large viewport inline, dynamic viewport inline. I don't think there is any ever difference. So they're all going there, logical or not. There's still fs, SVB, small viewport. Yeah, you can go here and like, I guess, like a slightly above because it's the logical property version of it. This gets grouped with that one. And then the dynamic one can go over here slightly above. We'll do that. There we go. So it's sort of like a better D, but not quite a D plus. Then we have small viewport min. I mean, these just, okay, small viewport min. I've never used any of these versions of them, but it's sort of like the V min, the V max, but just more confusing, right? So I know it's sort of cheating, but we're going to group these and I believe the D one on top for both just so it takes up less room on our graph here. Dynamic, whatever, I guess they also get grouped into this because I have my V min and V max here. I bet you the difference is so small, but I guess if you used a hundred V max or min, and it was the viewport, it's better if you're using the S one, I don't know, whatever. I can't overthink all of those. So I'm just going to throw them in there just because they sort of get grouped in with this. That's how I see it. And what I'm actually going to do is let's just, we're going to group all of this sort of together in one big mass of V min, V maxes, including everything else because there's too many of them. And then it says, there's my V min, V max, everything, whatever. Maybe if I play with it more, I'll find use cases where I want to use those instead of the regular ones. I'm not going to overthink it right now because if not, this video is going to get too long. And then finally, we get down to our last group of units, which is our container units, which are new browser supports, not the best, but that's okay because I said, I'm not going to worry about browser support for this video. So container units are amazing. And what I'm going to do is you're getting S tier because container query inline is amazing. So basically it's sort of like a viewport unit, but it actually serves purpose. I think because we're basing it on instead of the viewport, we're basing it on the container. And for font sizes and other stuff, as long as you're using it within a clamp, I'm cool with it. Again, do I give a viewport unit a D? Because I use them with, I'm bumping viewport units to a D. They cause so many, and that means VI comes with it and gets like the slightly better version. Because I use it within clamps a lot for responsive typography, I'm bumping it up. It causes so many headaches. There's so many people I help that just use viewport units like crazy. It still gets a bad mark, but I'm bumping it up for being useful for typography, which is also why this gets S tier, because with typography within a clamp, you have one font size. It doesn't matter where you're using it. It's just going to fit. It's wonderful. If you don't know about them, I'll put a video in the link because I love them. So that goes there. That's my inline. So I mean, that's sort of the same as this. We'll group them together. We'll say it's an inline, so it gets higher up. Continue query height is going to get AC. And the reason I'm giving it a C instead of the A is, first of all, I don't know how often I would use it. Heights are always just problematic with CSS. I'm giving it a D actually. We're running out of room. I'll just give it a D like all the way off to the edge here. The reason I'm giving it a D and make my graphic is because heights are problematic in general with CSS. So obviously we're very based on that container queries. You're often not on your container. You're often not going to want to have it as defined with the height. You're going to be doing a container type inline size and not size because size makes it hard to work with. And so just because this relies on you having, I'm docking at points for us having to have a defined container in the height for this defunction, because I find 100% there's use cases for this. And every now and then it'd be a little bit like these guys where you're going to have a perfect use case. You're going to be so happy about it. But there's a limitation to using it that you do not get with the inline ones. So because of that, it gets docked a whole bunch of points, and it's just less useful. You wouldn't have your font sizes defined with container query stuff, right? So yeah. And if you're going, well, with a vertical text, well, then you're using container query inline because your inline access is changing anyway. So there you go. So because of that, that means container query, we have container, whoa, whoa, whoa, okay. I didn't even know it. I just grabbed them all. I made this a little while ago before recording. We'll go with the ones I know. So this is blocks is going to get grouped with that because it's basically as useless. Again, there'll be times where you want to use those, but they're not as often. Container query M. Oh, this is the new, okay, these are the new ones that just got added. Oh, wait, we have the minimax, the minimax again, I'm actually going to dock these quite a bit, because they would both they're going in D also, because they would require us. I'm going off my, my figment doesn't like where I'm going. They're going in these are these will go off this side. I guess my frame, oh, we're going off my frame. I can make my frame bigger, whatever. I'll share this somewhere when I'm done. But they're going in D. Just because again, the same requirement, they won't really work if you don't have a defined height on your container. And your container has to be inline container or a size container instead of just an inline size. These are the new ones, these were just added are the most recent additions. Haven't used them container query CH. So it's looking at the CH of the container. So, hmm, this, hmm, where would I use these contain so I guess you'd have a define you'd have a container where you're setting up a font size, and then it's going to look at the font size of the container rather than looking at the font size of anything else. And I wonder, I guess that would fall to the viewport if you didn't have one, I'm assuming that could be kind of cool. I'm trying to think why I'd want it. Okay, so it's like REM, but instead of looking at the root, you're looking at a defined container. I think I'm going to give these bees, I could see them, I see all of these sort of falling into the X cap LH world where it's super rare, you're ever going to need it. But when you do, you're so happy they exist. And when you don't, you're never going to misuse it, because definitely some of these can be super useful, but they're getting docked because they're just misused and abused and used incorrectly. Whereas these ones 100% there, I don't think anyone's going to accidentally take a CQLH just guessing. But when you find out that that's what you need in a very specific use case, you're over the moon that it exists. And that's one of the things that I wanted to do by looking at this. Like obviously, same with these, right? Like you need these, you're doing print stuff, like boom, they're S tier all of a sudden. So like, we have a lot of units, you're not going to use most of them. First of all, half of them are viewport units. And then we have a whole bunch of container query units now. So like, you don't have that many units, right? The ones you're probably going to use are percentages, REMs, pixels, Ms, 90% of the time. Throw a few CHs in there and you're happy. I'm moving CH up to S tier. I wasn't sure, but I am. Just because I don't use it for a lot, but it just does what it does so well. It gets bonus points. I like CH. It's my favorite unit, I think. So it has to go up there, even though CQI slash W are sort of fighting against it. I was going to resist it and wanted the container query ones by themselves, but I changed my mind. But you're just super, you're relying on this small grouping of units. Right here is probably most of what every website on the internet has. And those are the only ones you really need most of the time. Sometimes you're going to need these other little ones that come up in useful cases, though. And then other times you're going to need a VH or an SVH could be super useful for the right thing. Do we put SVH and SVB up higher? I think we're going to, now that I'm looking at it, I'm like, why am I giving those C? They don't have the problems of viewport of the regular VH. And they don't cause problems really, right? Like, if you have VH, if you did height in VH and not a min height, I guess you're asking for problems, but I'm going to boost those up to a B. We're again running out of room. We'll create some overlap here just so we can sort of these two live together as well. And these are also similar. Well, they're different, but similar enough. They're like relative container query units. Yeah. So I'm putting a lot in the DNF down here also that you might use in the right situation. So I just want to say, just because I'm saying they're down here, maybe you have the right use case for them, you can still use them. Just be aware of the problems they can cause. And there's not as many decisions as you might think that you have to make along the way here. Right. So like, and again, most of the time you're choosing the same ones, but I also want to know like, what did I get wrong here? What do you completely disagree with? I hopefully didn't put your favorite unit is an F tier, but maybe I did. And let me know why I'm wrong in the comments or why your favorite unit should be an S and I put it as a D or whatever it is. Please let me know. And if you'd like to check out that flowchart thingy that I made, either video where I look at it and the link for that are right here. And of course, with that, I would like to thank my enablers of awesome who are web on demand, Andrew Simon, Tim and Johnny, as well as all of my other patrons to their monthly support. And of course, until next time, don't forget to make your corner of the internet just a little bit more awesome.