Content-First Breakpoints

Key Takeaways

You have a Figma file that shows you some design at various sizes, but you're left wondering when your media query should kick in to switch between those different views you have. Well, my front-end friend, the easiest solution is to use an intrinsic pattern that lets the browser figure it out for you. But I also realize that's not always an option. Sometimes we need a media query, and that's okay. But when we're working from static files, knowing when a breakpoint should kick in can be hard to figure out. Luckily, there's a really simple approach that you can take that I call content first breakpoints. And in this video, we're going to explore what I mean by that and how you can use this approach with both media and container queries. And also, we're going to look at a common mistake people make with container queries that make them seem kind of useless. And so, we'll approach how you should actually be using them in ways that make them just so much better than regular media queries. Before we get to the specifics of what I mean by content first, the most important thing about media queries is that you want to work with ranges of them rather than specific breakpoints necessarily. Now, when you don't know what breakpoints you should actually be using, a lot of people will look at specific devices instead and the sizes of the viewports on the different phones and tablets and all of that, but it's really important to know that there really are no specific viewport sizes that exist. And to take a look at what I mean by that, we're going to go over here to this website which is the ideal viewport doesn't exist. And this is um by set studio, which is the studio Andy Bell's uh studio where they let's zoom in a bit on this. They conducted a casual experiment to answer how fragmented are viewport sizes with over 120,000 data points. And they came up with 2,300 unique viewport sizes, which is just like kind of absolutely wild, right? Uh, and if we just come down here, I'm not going to go through everything. The link for this is down in the description below, uh, if you want to take a look at it. But when you come far enough down on here, they actually have a lot of the different viewports or they have all the different viewports, uh, that they had. And like you can just see like all these different sizes are coming through. And it's actually kind of ridiculous. And you can go through this is just like the top 100 or something. And then you can click through and see all of them if you'd like to. But I think the most important thing here is if we come and take a look at like this the medium and large and extra large points where like the common 678 I'm sure you've seen this and use this there's a lot of common places there's this 1024 breakpoint as well and like they're showing actual devices that use these are are there's not a lot of people running things that actually fall on those break points which is a good thing in a way u but you know we want to avoid sometimes spe these very specific sizes but that just shows you like how infrequent specific things might be at those common sizes that you might be thinking of. Uh, and then break points that come directly from Figma. So like this is when you're choosing the frame sizes in Figma, some of the defaults, and how basically a lot of these don't actually come up as often in the real world as you might expect. And the the big takeaway of all of this, which is what I'm trying to hammer home as well, is the main point we're trying to get across is that you simply do not know how users are going to visit your website or app. instead of making design decisions on strict limited breakpoints, keep in mind the sheer amount of fragmentation there is in viewports. And then perhaps one of my favorite things uh that Andy talks about is the recommendation is always to be the browser's mentor, not its micromanager. And I agree 100% with that. Uh we're not going to dive too deep into that, but I will include a link to this post uh as well, cuz that's another one that you can check out and it's really definitely worth reading. And some of those break points that we just saw in that, they come from common places as well. I think a lot of the rise of that actually came from Bootstrap cuz here we can see uh there's the 768 that is right there for the mediumsiz breakpoint and uh you know with Bootstrap all of the breakpoints that came with it. This was super useful back in the day but the one thing we have to remember with these is because people will take these and use these in their projects cuz they don't know what breakpoints to use. So you just come and add these to your projects. you you start using them and it is a decent starting point, but they're also extremely generic because this is set up just to be like this has to be able to work for anybody's project and not specifically for the project you're working in. And that's the same with uh Tailwind. And in both of these, it's easy enough to configure and change them, but Tailwind uses a lot of these same breakpoints that Bootstrap did, just because they're common and they sort of do fall within the ranges where things tend to, you know, it makes sense. A lot of these break points I usually use slightly different ones than these when I'm doing my own thing. I find this is a little bit too narrow. A lot of the time I end up with one that's a little bit bigger. But it again depends a lot on the project that I'm working on. But the one problem I do find whether it's something like Tailwind or Bootstrap or anything like this, especially with Bootstrap having this many is what people start doing is thinking they need to use all these break points because they're available to them. And I see a lot of beginners making this mistake where they just start throwing in all these changes that are happening when they don't actually need all of these break points. They might need one or zero or two and but because they have them available for some reason they feel like they need to use them. And so it's one of those things where you really need to look at it on a project by project basis when deciding what breakpoints you need and how many. And that's where this content first approach comes in cuz I've had many projects where I've only used one breakpoint. And some layouts you create might need a lot of break points and some might only need like one like what I was talking about. Or heck, you might not need any break points at all if you have a simple enough layout. It really comes down to the complexity of the layout that you're creating. A single column layout for a blog probably doesn't need a breakpoint. Maybe you want to change your font sizes or something like that. Though there's other ways that we can approach that as well. Uh if you have a main area with a sidebar, maybe you need one break point. and when is that sidebar going to wrap underneath? Or maybe you have a complex layout like a dashboard or a bento grid, in which case you might need several breakpoints. And in all of those cases, this is where that content first breakpoint approach comes in. It's the content that is within these layouts that should determine the general break points that you're using and not anything else. Not some arbitrary numbers that just make sense for somebody else's project or some generic numbers that you're just grabbing from somewhere else cuz those again might work in generic senses, but there might be some awkward places where it's just not quite working in your own project. And so you've made it this far and you're going, "Okay, Kevin, this is fantastic. I'm on board, but how do I actually figure out what numbers to use in my media queries?" And the way I do it is I tend to focus on when my layout starts to break. And when I mean that, I mean like when does it start to look ugly? And I don't think that's the definition of a break point. It's just when the layout changes from one thing to another. But I really do think that idea of when does it break? When is an overflow happening or when is the content becoming too squished? Okay, now I need to start focusing and figuring out where a media query might make sense. So yeah, I I'm pretty sure that's not where the term comes from. I don't think so, but it I find makes it really easy to remember. Add a break point when things start to break. But there's a really big caveat here, which is that I don't want you to micromanage your viewpoints either. If you start hunting down for that pixel perfect point when that layout is shifting, all that's going to happen is you're going to have tons of break points across all these different things. Like this component might have one, and this layout over here has one, this other thing has one. And when they all start changing within like 12 pixels of each other cuz they all fell within a similarish range, but it was a little bit different on when things would start to go wrong, then all of a sudden one thing changes and then the other thing changes, but then it doesn't quite fit until you hit that 12 pixels over on the other side and then they start coming back together, which is why we tend to want to focus on ranges. If I see that, okay, in this general range is when stuff doesn't look good, I'm going to put a break point around there and I'll sort of tweak it a little bit to make sure everything is working. based on that one single break point. And so let's dive into an actual example here to see what I'm talking about because it's nice to talk about it in abstract, but it's nice to see it sort of come into play as well and actually see how I I might approach this on a layout that I have. And so here the way I have this set up right now is we have this grid auto column coming in. So this is that intrinsic layout that I was talking about earlier where it just figures it out out by itself and I'm using the auto fit for this. And maybe I'm really happy with this, but my designer comes and goes, "No, Kevin, I I need this to switch from just being one card that's like this to at one point we need it to become three." And that just needs to happen. So you figure out how that's going to do it. I would say if you're actually in a discussion with the developer and they're coming back and saying that, the very first thing to do is be like, "When should this happen?" Maybe you sit down with the code and go like, "When do you think this looks good?" Cuz they're the designer. But if you don't have that option, we're going to be talking about how we can figure that out. So the first thing I'm going to do is I know I need to go up to three columns. So instead of the grid template columns here, I'm going to come and say this is actually going just to be a repeat of three 1 fr. So it's going to give me three columns all the time. It's going to get way too squished and it's going to be problematic. But at least now we always have the three and we can sort of figure out what we're going to do from here cuz we can tell right now my layout is broken. I don't want this to look like this. I have overflow and issues and it's not working. So my layout is broken. that helps me figure out what breakpoint I'm going to use. The other part here is also just I have this 620 that's floating around here with a media query, which is when I'm going from a stacked layout like this to adding in the sidebar that's right here cuz my layout goes from one column to two columns. So that's also something I need to take into account in this specific situation, right? Because if I'm going from this to this, well, this thing is changing at different points. And even is the 620 the right time for this to be happening as well, you know, and should that be a 640 instead or a 660? And that's really one of those things. Once again, maybe I'm looking at it here and this is kind of really ugly. And I don't know. We're going to have to sort of make these different things work together. And that's the other thing I want to talk about is anytime I'm looking at like, oh, I need these things to work together. Maybe I want to be using a container query instead. But we're going to start with just the media queries to begin with and then we'll work our way up to using container queries instead. So here, let's just focus on this area for now where it's broken. It's broken. It's broken. And then like technically it's no longer broken at this size cuz I can see everything, but it is kind of squished still. So maybe I want to go a little bit bigger than that. So I'm at almost like 980 pixels around here. So that's sort of that range where okay, I want to do that. I definitely don't want to do it at this break point cuz that would be when we go up to the like that's here. So I can see that that's broken. So I know I can't use this existing breakpoint. I do need a new one. And then I go okay it's starting to work around here. And this is partially through a lot of experience through other things that I've done. But I also know just through you know having done a lot of this that this actually does make sense as a breakpoint for me. So I can do an at media width is greater than. I am using the range syntax here. So this would be the same as a min width uh as well. I just I like the new range syntax better. So we're saying the width is greater than about 980 pixels. Maybe 960 is one that I've used a ton as well. So if I was doing this without playing with it, I probably would have started with a 960 and seen. So let's go with that. And I come in talk about vibe coding, right? That's like the big topic now. Everybody's into vibe coding. Like this is like vibe breakpoints, right? We're just we're figuring out how it works based on vibes. And then I look at it and I go, "Okay, it's sort of working in a way, but I actually find it's getting way too wide here. I guess I could live with that." Um, I think it's way too big here. Around here, it's working. So, I might actually want to adjust this and not use it. It would depend a little bit on other things, but I do think it's clicking in a little bit too early. Uh, so I might actually change this to like a 900 and then see. And I'd play with this. A 920 tends. I mean, it's not perfect. I don't think I'm ever going to get a perfect one, especially because the images, the way they're getting cropped. So, this might even be something where the handling of the height of the images here might have to be changed and then it could look really good. Um, so that's another approach that could come into things cuz as it's getting wide, the max height on there probably would look a lot better if they were a bit taller. Um, and then here, that's actually working pretty good. And so maybe that 900 works there. And again, if this is the first time I'm using that, I'd want to make sure that 900 breakpoint, if I do need it in other places, is something that also makes sense because I don't want a 900 here and a 920 somewhere else and a 915 somewhere else. I want to stick with these general ranges that I'm using and making sure that they're going to work across the board throughout my project. But you will generally find if this is working for this layout, most things are going to start falling into these same things. And this is also why I don't like going with or the 992 here could potentially work. Um, I was thinking of the larger one from Tailwind actually with this 1024. Like I find I like having a break point in between these two in so many of the things I do. I have something that's somewhere in that like 800 to 960 range that like and this just ends up being a little bit too small and this always ends up being a little bit too big for me. And so and if if I stuck with these, it would just have some awkward layouts at certain points and I don't know when users are on those points. So that's why I like sort of just getting a general vibe of what's happening with my layout depending on so many things. And the reason there's so many variables at play is everything comes into this from your font sizes to the type of layout you have and so many other things along the way. So you really do want to be careful with it when you're trying to figure these things out. And it's why it becomes harder to have these general ones. though again you might find like a 960, a 920, 860. Those like there there's certain numbers that you're going to you might find start repeating themselves a lot in the different things that you're doing as long as the types of layouts you're doing are similar and then you'll get some random new project where all of a sudden everything you're used to doesn't quite work. But by having this type of approach to it, you'll very quickly find what would actually be working for that other project. Now, the one problem I am running into here, at least in my opinion, is this is working fine here. And I think it's actually looking pretty good. I'm not in love with this, but again, maybe I'd talk to my designer, say, "Can we make these cards a little bit taller?" Or I would just make that executive decision if the designer isn't there to talk with me, cuz I think the client would get mad at me for making something that looks like this. But then over here, maybe I want a little bit of a different layout. Maybe it should go from like two columns or maybe I don't know maybe I'm wrong but at one point or let's just exaggerate this a little bit for our purposes. I'm going to bring this up to the 920 as well. So we're going to say 920 is when the sidebar comes in. So we're doing single column layout and then we get to here. Uh I think this will work better for for demo purposes even if it's not 100% realistic. And actually in this case I think we can make it realistic when I see something like this where this thing and let's on my grid here let's just put a border on here. border is 5 pixels solid red. When I see something like this now, where in this situation I'd want it to be three columns, then maybe here it's a little bit too narrow. And this the layout of what's happening in here should be shouldn't really be dictated by the size of the viewport anymore. It should be dictated by how much room is available within here because that's much more indicative of the amount of space that these cards have to become three columns. And so to be able to do that, maybe instead of a media query, I should actually be using a container query here. And for me, this makes a lot more sense because I can I'm controlling the layout that's happening here based on the size that's available for these elements that are right here. And I like that approach a lot more. Now, there is a little bit of a limitation in how container queries work. So, one thing you will have to do in this specific situation. It really depends on the type of thing that you're looking at, but it is one of those things that you'll often be doing if you are using container queries is we need to have a defined container. So, the grid can't look at its own size. The grid that I'm creating here has to be looking at the bigger thing that it's inside of. And right now, it's going to be looking at the layout. But the layout, if we come and take a look at that, if we put a border of three pixels solid lime on there, just we have something different. Or maybe we'll do a dotted on there, uh, is this outer one that's going full size here. So, if it's going this entire size across from here to here and I'm looking at the size of this, it's not really that much help more helpful than a media query because it's still looking not quite at the size of the viewport, but close enough. So, what I'm going to do is I'm going to come here and I'm going to do a dot I'm not even going to call this grid container cuz that was how I'd started doing things like this when I was using container queries. But I'd come in with a grid container like this and that would be my container for my grid. But then I kept having all these different containers that I would have to make that were all essentially the same thing. So I'm just going to come in here with a container or a class of container I should say and I can reuse this in other areas. Some people might not like this name because a container is something that I'm using the name of wrapper here for that contains the content and holds it within a specific place. So if you do want a different name for it, I'll say that that's 100% valid. But it is the reason that I've stopped using container and I've started using a wrapper for holding content in the middle of the page. And I started doing this a while ago before I started even using container class like this. Uh just because I saw that there could potentially be this weird naming thing where we have container queries, but I have a container that's not related to container queries. It's kind of weird. So for me, that's how I name it. If you want a different name, go for it. Or it could even be like inline container or something cuz we're going to make this I'll do that. I'll call it inline container for the demo. Uh and maybe that'll be a new name that I use just to make it a little bit less confusing maybe. Uh so if I do an inline container and this all I'm doing is a container type of inline size and in doing this nothing changes at all. It's just this extra layer for a div that now if we look at that inline container. Let's do a border of 10 pixels dashed white just so we can see it. I'm making it quite big to make it really obvious where it is because it's the same size as this red box. It's just the inline container for this grid right here. And so we can now take off that border because we definitely don't need it. And I can come on here and instead of a media query, I can come in here with a container query now. And for a container query to work, you have to have a container defined somewhere. So the container type of inline size or just a container type of size somewhere defined on your page. If not, a container query just won't do anything because it always looks for the nearest defined container. So, in doing this and switching this over to a container, I just realized I did that on the wrong thing. We're going to do that on my media. And we're going to come down here and on my grid do this one on the container query instead. Container. And now it's looking at the size that's available to it. And then the 920 is way too big cuz we're never actually like in this area, we're never getting to 920. And then over here, we're eventually getting to it all the way out here. But that's really really big. So this is for me a much better way to work though because I can say okay when this red box now is let's say I don't know 600 pixels wide. We could decide. And this isn't how I would actually do it though. This to me is falling into the same trap of having to like magic number your way there and guess at content first break points. And it really is just this like magic numbery type of thing. And so don't if this is what you've gotten to just hold out for a second. Uh cuz we can see we get my cards and then they stack. And then at one point we get to here and there's a really small let's make this a little bit bigger. We'll say 700 uh just to see the difference. So we go from single column to three columns back to single column and then back to the three columns there. And it's all based on just the content of these. But where I find things become more useful here when I'm doing this, especially if I know I'm going up to a specific number of columns, is I can come in here with a little bit of math. And so I can come in and say this is a calc and I can say something like okay I'm not even worried about just this general amount of space that's available. I'm worried about like how big is each one of these cards is a minimum size and this is something you could probably talk to your designer about like what's the smallest sticking to actually get to and it's much easier to do that based on like how big should this one thing be rather than trying just to like magic number your way there on a bigger picture type of thing going oh it looks okay now. So I go actually the minimum size I want my cards to be is 170 pixels wide. And so I can say that when my calc of 170 * 3 comes in, we're going to go up to three columns. So when we get to the smaller size, we can see it's actually at this point because that 170 is quite small. I thought it would be bigger than that. Let's try a 240 instead cuz that's getting a little bit too tight for me. When we get to that 240, which is actually looking pretty good as a minimum size, we go up to three columns. So then we go to here. It's looking like that. And now we're doing a much more of a content first approach where it's really based on the size of that individual piece of content right there. And with things like this, you might be saying, "Well, Kevin, this is going to get very micromanagy." And it will be to a certain extent because different components might end up with different breakpoints, but it's always going to be based on what's happening within that one thing. And it keeps all the CSS together for that. Even if you weren't nesting, right? I could take this out uh and do the container query the other way around with my grid over here. I would still generally keep all these styles together for this thing that I'm creating. So that this is sort of like the way this one thing is going to work. And it my larger layout can be functioning in a way that makes sense for the larger layout pieces to be moving around, which I would be doing with media queries. I'm going from two column or zero columns to having the sidebar. That makes sense to base that on the media query. And then the pieces inside of there are adapting to the space they have available to them within that system. So when that layout shifts, it's figuring out, okay, I have this much space available to me. I can maneuver or change or do whatever I need to do within this space that I have available. And there's more we can do with container queries, though. They really are kind of magical. And so here's this other example that I have set up. And I use this in a talk I did with for smashing conference. So I'll put a link to the full talk there. It goes into a lot more um advanced stuff we can do with container queries than what I'm looking at in this one. Uh and I got this trick from the picilly blog. So that is linked in this code pen. The demo is also linked in the description. And here I'm going from one layout or from this layout for it goes from a stacked layout to a two column layout. We can use a media query to decide when that's going to happen cuz that makes sense. So it's 720 pixels where I feel like that needs to come in. That's great. But when it's stacked like this, it looks like crap because now my image is taking up too much space. So we can create this adaptable image class. So I have an adaptable image div that has the image inside because again I need to have a container type that's defined. That's the one limitation of using container queries. And then in there I can say any image I have that's inside of there is going to adapt depending on the situation that we throw at it. And you can see I'm limiting the total height. And I'm exaggerating here. And we don't want to be loading in images that are much bigger than we need and just cropping them down, especially on mobile devices. But I think it illustrates the point really well of the type of thing we can do where I have this small image that is then getting bigger. And the reason this is really cool is because right now it's working when the break point happens at this 720, but it's always going to be based I don't have to like worry what this break point is or this adaptable image could be brought into other situations where the same type of thing is going to happen. And it's always based on when the width of this div is larger than 70 VW. Because if the width of the container there is larger than 70 VW, it means we're not in a two column area anymore. We're probably in a single column. And the reason you want 70 VW and not say 100 VW or like 99 VW or whatever you might do there. And it's because uh with this split, let's say I had a padding in line of 4 RAM or something. And so I'm keeping it off the edges of the viewport. We might not always be at the full width. So sometimes we're coming in a little bit narrower. And that means like if I was basing this on being 99 VW, this would never kick in because it's never reaching the edges of the screen. So something like 70 where we know it could adapt to the situation being thrown at it and stack and move into these different things. And we could use this image in a whole bunch of different places and it's always going to behave the correct way cuz it's always based on the container size and we're doing something we can't really do with container queries because we're comparing an element's width to the size of the viewport. Whereas with a media query, we're only ever looking at the viewport. So it just opens up this extra dimension of these different things that you can query. And it doesn't just have to be viewport units. It can be pixels. It can be rem or CH or other units too that can be really really useful. And so there's definitely a lot to think about. You might be looking at this going, "Oh my goodness, maybe I'm even more confused than I was at the beginning of this video." And if that's the case, really go back to the very early stages where I'm basing my break points just based on how the content is working. Is the content breaking here? It's overflowing. It's getting too squished. Things just It's getting too wide. Things look ugly. Okay, I need a general break point here. and let's find something that works for the smaller sizes, the bigger sizes without overdoing it and throwing a whole bunch of break points in there. Or if you like that intrinsic layout that I was looking at before where the browser just figures it out for us, which is always the best when you don't even have to worry about it. The break the browser does it for you, I have done a video where I looked at five different intrinsic patterns that don't require any media queries. And that video is right here for your viewing pleasure. And with that, I would like to thank my enablers of awesome, Andrew, Simon, and Tim, as well as all my other patrons and channel members for 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.