Recommended Breakpoints

[00:00:00]
>> Kevin Powell: One of the questions that comes up with media queries is how do you pick a breakpoint? Every time I've been doing one of these demos, I was like, I guess we'll use 800 pixels here, or let's use 720. I just sort of throw random numbers at it, and often it can feel like you're doing that when you're picking breakpoints. They can feel very magic numbering. One solution in the old days was to use common devices.

[00:00:23]
So there was like people using the iPhone size versus an iPad size versus a laptop like the Apple laptop, the MacBook, and then go up to the desktop. Then we had a proliferation of devices and every, you know, just in the Apple ecosystem there's however many that we have to worry about, so that idea people quickly realized is probably a bad idea. There's some general breakpoints out there. Bootstrap and Tailwind are two that have a lot of generalized breakpoints.

[00:00:53]
So just looking at theirs quickly, this is Bootstrap's, who sort of were a big part of the responsive design revolution at one point, just because when we had to do float-based layouts, which were hard to do, they helped us out. They have these sizes that they've picked. They're relatively arbitrary. They've picked them because they feel like they work well for general scenarios that run into. If we jump on over to Bootstrap's, who's, they had to make some decisions on this as well, and if we look at theirs, they're not the same.

[00:01:27]
Actually, this is the same, interestingly enough, 768 is the only one that the two of them have in common, I believe. There's some similarities, but they are different as we go up in the sizes. They had to, they've created products that are for anybody to use for any given situation that might be thrown at it, so they had to make some generalizations, some educated guesses, and come up with sizes.

[00:01:50]
So they're not a bad starting point, to be honest. They work for lots of people, so you could probably come in and safely use them. My one issue with them is they've had to create a lot of breakpoints because they need to accommodate all the different situations that different people might run into. And when people have these available to them, they feel like they need to use them. In my own experience, I don't tend to come in and have 5 breakpoints in a project.

[00:02:19]
It just seems like a lot in a lot of the things I'm doing. It might depend on the type of project you're working on. If you're doing a web app that 90% of your people are using phones for, you probably might have two and just have a very basic layout for your website, or if somebody does use your web app on the computer, or you might, I've had people get very mad at me when I've been talking about some responsive design stuff that are telling me, oh, I only do, you know, hospital, this one application that's a web app for a hospital that only is used on desktop computers, like, yeah, in your situation, you don't have to worry about that.

[00:02:51]
So look at the situation that you're in and make educated decisions based on that. And I would say that the other problem with it, because theirs are generic, it might not be perfect for your situation. My general rule of thumb is to create a breakpoint when the layout breaks. So, and it's a general rule, but here, I sort of have to decide when these columns are getting too narrow. And so maybe around here they're getting too narrow.

[00:03:17]
CodePen, you do have like a little visualizer down at the bottom here. It's really small and I can't make that bigger by zooming in, but it shows you the screen size or the viewport size. So maybe I decide here, in this case, my, we'll do the old school way, min-width. Just to change things up a bit, 780 pixels. And not square brackets, curly braces around that. So now we get at that breakpoint, it switches back and forth and maybe that's good.

[00:03:59]
Except then the body, the font-size changes and they go really big just to exaggerate, but if you make that change and you have a larger font-size, now it's too narrow. Those are really getting squished again because the text is bigger, and breakpoints tend to be very focused on the content that's inside and when these things are going to be changing. So it is a little bit of a case-by-case scenario of you figuring it out based on the content, based on the layouts that you're working in.

[00:04:23]
I really wish there was a rule of just use that breakpoint. Again, using either Bootstrap's or Tailwind's breakpoints could be a really good starting point just to get you having something, but you can always tweak those within your own projects. Common ones, you know, we saw the 768 or 860, that was a good one. They both used it. Not a bad starting point. I often have something that's more like 860 or 920.

[00:04:53]
Depends on the project, often depends on font sizes that you're using and everything else. The one thing I will also say though, is don't pinpoint this. I'm saying it's when your layout breaks. Please don't come in with like, it's at 927 pixels for this part, and then you have another breakpoint later on in your project that's like 937, and then another one that's 932. If all these pieces are sort of changing within a very close range, no developer or nobody who's not a developer does this on a website, by the way.

[00:05:21]
It's only developers who resize and see how things work, so your users aren't going to see these weird jumps, but the more really closely linked breakpoints you have where things are changing, you might get these in-betweens of some of them where something just goes wrong and it becomes very hard to manage. So if you have something that's around 927, just reuse that for all of them, it'd be close enough for most of the situations that you're running into.

[00:05:47]
But yeah, I tend to go with the see where things are breaking. You probably have a few that you're using all the time, and just, if you don't need 5 media queries, don't feel like you need it just because something like Bootstrap or Tailwind has that many available to them. Would you recommend like custom properties in that case, so you're like defining them in one spot? I wish I didn't talk about that, but let's, I really wish.

[00:06:19]
We could do a root. Actually, I'll explain why this doesn't work, but let's say we did, small, right? And then we say small is 700, 670 pixels wide. And then I say, @media. I'll leave it. We'll nested in the flex container just to make it a bit easier. @media var small. Or I did my var wrong. I won't even finish writing the whole thing out because it's not going to work. There's momentum on something that will enable this.

[00:06:53]
There's custom media, that's something that's been in the works for a long time, looked like it wasn't going to happen. Chrome's currently working on it. I'm getting some bug report filings coming in on it. The reason this doesn't work is even though I've nested this in my flex container, media queries and any at-rule are global, so they're living off outside of any selector. And the custom property isn't.

[00:07:17]
This isn't available at the global level, it's available inside the HTML element. So the media query can't actually see this value over here. So there's no way, and actually this should have been, I didn't even write that correctly, but it still wouldn't have worked even if it had. We do like a width is greater than, right? So. Eventually, maybe this is one reason people still use preprocessors is for this type of thing, we're just talking about that a bit earlier with Ryan, but yeah, it'd be really nice if we could do this, eventually we might be able to, but for now we can't.

[00:07:52]
Yeah, I actually saw someone write about this a couple of weeks ago. Piccalilli came up with a workaround by using containers. With container. Yes, I remember I read that article. I'm trying to remember it's, yeah, so it's using container queries, I think instead. Yeah. And with style queries. Yeah. Yeah. So it's really cool. Cutting edge, very cutting edge, though, we said we wouldn't be able to use it now in production.

[00:08:16]
And looking at it, I had to read that a few times to sort of wrap my head around exactly what they're doing. But Piccalilli is a very good resource, though, and it was a really clever approach that they used. When it comes to media queries, I said we can do greater than, less than, there's the min-width, the max-width, these approaches are depending on how you're doing it, you'll often hear mobile-first design or desktop-first design.

[00:08:40]
Mobile-first is where you worry about, you design for small viewports, and then you use media queries to add stuff when you're getting to the bigger ones, and a desktop-first is when you design for the desktop and then you use media queries to change the layout for the smaller viewports. People always ask me about this. People are very opinionated about this topic, by the way. They, it's one or the other, they get very angry if you disagree with them.

[00:09:03]
Mobile-first is easily the more popular, but there are diehard desktop-first people out there. Desktop-first can feel more natural because we're usually developing on a desktop computer, so we have the big one and then you're like, oh yeah, I need to make my smaller stuff, so you're adding in media queries to change what it looks like at smaller screen sizes. I prefer taking what I call the path of least resistance, which is, I don't really care which approach I'm using, as long as it means less code for me to write.

[00:09:34]
Most of the time that means mobile-first, because you write mobile layouts tend to be simple. They're just stacked layouts on top of each other and then we add columns in or we add some other sort of complexity, more complicated layouts, fancier things going on, more animations, other stuff as the screen size is getting bigger. That's not always the case. The classic example are navigation bars. So with the navigation, we've already seen how we can make a nav bar like this, display flex gap, it works.

[00:10:03]
That's all we really need. Maybe there's a flex-wrap on it. It's like 3 lines. As this gets smaller though, it's very common to run into a situation where all of a sudden they go this way instead, and I'm adding a background color and I'm changing the direction of them and they have this big hover effect and they look much more fancy. So in this case, it's actually more complex at a smaller screen.

[00:10:29]
So in a situation like that, I would do my very simple. This is a really old demo. I think I'm using jQuery down. Oh, no, I actually updated that. I thought it might be one where I was. But if I come down here, I can create just my regular, all screen size, primary navigation, display flex, gap of 2. And then I have my media query, changing the flex-direction, positioning is coming in, we're going to be talking about that soon.

[00:10:53]
I'm adding a background color. I'm adding all these animations. I'm doing other stuff at that size. So when I say the path of least resistance, what I mean by that is find the way where you're adding the complexity through media queries instead of trying to overwrite things that you've already brought in. If I did it the other way around and I took a mobile-first approach there, I'd have set it all up.

[00:11:13]
And I'm going back to the defaults. Let's remove my background color. Let's change the spacing back to zero that I had originally on all of these things. I'm reversing course within the media query. It feels very cumbersome and annoying to do. So I always try as much as possible to add complexity through media queries. Whether it's mobile-first, desktop-first to me doesn't change anything. It's the easiest thing to do, less code, more maintainable, and easier for everybody.