Intrinsic Layout

[00:00:00]
>> Kevin Powell: All right, so with everything we've done up until now in place, the next thing that we wanna start doing is looking a little bit more at layout. Everything we've done until now has to work across all screen sizes, so we haven't had to think too much about everything that we've needed to do.

[00:00:15]
Whereas now we're gonna start coming into we need columns, we need other things, and we need to decide if we're doing it mobile-first, desktop-first. How we're approaching things to make these types of decisions. Though, I do wanna say, I do think this whole debate thing, most people I think do lean mobile-first.

[00:00:32]
There's some people out there who will always be like, I only do desktop applications that are for enterprise so I don't care. And I'm like, well that's great, then it is a case by case basis. The thing that I usually try and advocate for is taking the path of least resistance, which is just do the one that means you write less code and it's gonna be a lot easier to maintain.

[00:00:53]
One example that I like to give is just doing columns, say you're using display grid, if I did it mobile first, I can say, display grid, put a gap, and then I just add the columns at a larger screen size. If I did the same thing with desktop, first, I'm setting up the grid, I'm doing the gap, I'm doing the columns, and then I have to change my columns again to go back to what the default behavior already was.

[00:01:15]
That just always seems a bit awkward to me when I need to use a media query to put things back to where they were before I wrote anything. The other example I give for this is Mobile navigations, which we're gonna be eventually getting to where it doesn't really, it's the one or one of the few cases where a mobile navigation is actually a lot more complicated at smaller screen sizes.

[00:01:38]
And if you were to do a mobile first for your mobileNAV, and then you have to come in with the desktopNAV to simplify it, you're writing a lot of code to go back to the starting code that you already had. So that's one of those times where maybe you go, well actually it makes more sense to use a max width media query or a desktop first approach.

[00:01:56]
Before you choose any of those, though, one thing, or we'll talk about break points too, but one thing I would talk about, I like to talk about is the idea of intrinsic layouts. This is a term that was coined by Jen Simmons, which is when you're not worried about the media query at all, you're letting the browser figure it out for you based on different information that you're giving it.

[00:02:13]
So one example of that is when using Grid, if you're using the autofit syntax, which we're gonna have to use for our second page eventually, where the browser figures it out all on its own. We don't actually have to do anything along the way for that. We're gonna see this later on, so we'll talk more about that when we get to those stages of building that out.

[00:02:32]
But our navigation is actually one area where we could come in with a nice, intrinsic layout without having to worry about things too much. We will eventually do it in a bit of a fancier way, but I'm actually a big fan of not having to do that. I just included it in this project cuz I know it's something that most people do need to actually implement in real-world projects.

[00:02:54]
But if we come and take a look at our navigation at the top, let's go look at the markup that we had for it. Use my mini-map here to go all the way up, I'm gonna turn off Word Wrap. Just so we can look at the structure of it, I'm not worried about the content.

[00:03:09]
I have a site header, I have a wrapper, and then I have an image and a NAV, UL doesn't really matter too much, we'll look at that in a little bit. But we basically have this wrapper, and then we have this NAV in this image, I need to separate them and I need them to be in separate columns.

[00:03:24]
So I need to have some sort of layout here, you could come on your wrapper and do something, whether it's flex or grid on something like this. I tend to, and a very common pattern with headers cuz headers often have this header and then inside the header you have and then you have a layout in there is coming in with another div.

[00:03:45]
And I'm gonna call it site-header-inner, and I talked about not being a BEM person as much anymore. This is one of those cases where I still use the BEM naming pattern of the double underscore. Just to say when something is meant to be used inside of something else, basically.

[00:04:07]
The idea with them is it's the block, it's like an inner block element modifier. It's an inner element to the site header block is sort of how they do it. It's to say that this only use case the only time you should be using it is if it's in here.

[00:04:22]
I don't use a data attribute, or anything like that, cuz the connection doesn't seem to be there for me, I feel like it still makes sense this way. This is a place where you could just do a site-header-inner if you prefer, there's no harm in having that. The advantage of using the double for modifier classes and the double underscore for saying that it belongs in something is it just creates like a visual separation.

[00:04:49]
You have the name of the thing here and then the extra bit of information coming after it separates them. So, when you're scanning through something, it's easier to tell what it's doing. So I'm gonna go with that approach, but if you prefer a different name, you can. But I really do think I don't want it necessarily on my wrapper, even though, at the end of the day, it wouldn't cause any harm if it was there.

[00:05:10]
I just like separating those concerns between what those two divs are doing. I know people don't like having too many divs on something, but I don't think it causes any issues here. The other thing I need to think about now, actually, because we were working on our site header, and we're gonna be getting into more pieces along the way, is the site header a layout.

[00:05:30]
Even though like and actually, we could even call this site header layout if you wanted to, instead of inner, just to be more clear, I use inner because it's is what I've always used. But if you like layout, because creating a layout that works, so because it is something where we're controlling a layout, the first thought would be, let's put it in my layouts layer, because it's a layout.

[00:05:53]
But as much as possible, I like using my layouts layer for generic layouts, these are things I could just Plug and Play and use absolutely anywhere. Whereas if it's something that's specific for one use case and it should only be used within this one area, that's where I like actually coming in and creating a new layer.

[00:06:11]
So we'll come in here, I'm gonna collapse the base one again, just to clean things up a little bit, collapse them all. And After my layout, but before my utilities, cuz I like having my utilities as the last layer to give it the highest importance, is to do a layer of components, which are just sort of these one-off pieces.

[00:06:30]
This is my site header, I'm only doing site header stuff, or it's my site footer, or it's gonna be the card, or other things like that. And so I can do my site Header, I don't know if I need to style anything on that right now, so I'm not gonna put that selector, we might need to have it after.

[00:06:45]
We probably will, but I'm just gonna do the inner right there, throw display flex on here, so we get two columns, and you can see right away that they're going next to one another. And then I can do, a justify content, ooops just defy content of space between if you get mixed up between the different spacing things or even justify versus the line items.

[00:07:11]
It's the same as a lot of beginners when very early days, when using margin and padding, it's easy to mix them up, try one, if it's the wrong one, you do the other one. It's easy enough to switch between stuff as you're learning them, but I want the space between so it pushes them as far apart, as far apart as possible.

[00:07:33]
Then we could do the same thing inside there, just for our navigation, I think everybody's used to doing that. So on my NAV, I have my UL that's in there, so I can select my primary navigation. And in this case, I'm just gonna use nesting, cuz I find it a little bit easier if you prefer not to use nesting.

[00:07:57]
This selector could just be your primary navigation UL like that, so, primary navigation UL and I can do a display flex gap 1 rem and that comes together. And Flexbox is really awesome, I made a bobo there, there we go, Flexbox is really awesome because it just stuff happens when we use it.

[00:08:25]
Everything's going next to each other, it looks really good, the problem with Flexbox is it sort of tricks us into looking like it's responsive. But what happens is when you get to these smaller screen sizes it just causes overflow, because the elements flex, they go next to one another, they don't do anything from there.

[00:08:42]
And then we feel like we need to come in with media queries or come in with other solutions, but as much as possible, talking about intrinsic layouts. So the idea here is, with your flex, we can do a flex wrap, on that. So now, when this runs out of room, instead of getting stuck there, it's gonna wrap and go underneath.

[00:09:05]
And it's really, really simple, the one thing is they do get really close to each other. So you could also put in a gap here, whatever space you feel like is appropriate just so it wraps before they actually touch each other cuz it looks kind Kind of ugly if they're touching each other.

[00:09:20]
And just like that, we have something that works across different screen sizes without having to come in with a media query, decide where a break point is. Stress about any of that, the browser just figures it out based on the space that's available. I would actually argue putting the flex wrap on the UL is also a good thing.

[00:09:37]
Just so if ever those once that wraps like here, these can also wrap as well. Hopefully, nobody of your users is on a screen this narrow, but it just makes it a bit more robust and you don't have to worry about it, which is always really handy. The other thing I'll say with wrap, if you're using it, is when things wrap, the visual spacing looks different when it's between the rows and between the columns.

[00:10:04]
So the visual space between discover and mushroom guide looks pretty narrow compared to the visual space between the discover and the FAQ. Even though it's actually the same amount of space, it's using the gap of one REM part of that's just how font rendering works. Cuz there's often a little bit of extra space on the top and on the bottom of the funs.

[00:10:20]
And there's trick of the eyes things that just happened, so the combination of both of them. The spacing always looks a little bigger, so usually or use the short hand here 0.5 maybe the same thing here o.5 rem. So to be 0.5 rem on the top and the bottom and then 1 rem on the left and the right just officially to look more balanced though.

[00:10:39]
Not something you need to do but most of the time when I have wrapping I do find I have the top and bottom wrapping end up being smaller. The only exception to this was if it's not text. If it's things that have background colors and padding on them, then you'd want consistent spacing all the way around.

[00:10:55]
But it gives us a nice mobile navigation without having to stress about it or do anything and use my personal side its so much lower friction and so much less work to get something working. The last thing I will do, is just do very quickly, I said we probably needed, side header.

[00:11:12]
You can even do this on the inner but budding lack on rem to add some just to make sure it does not touch the top of our screen to give us some little space on the bottom as well. And we can close the dev tools, and there we go, we have a responsive navigation, intrinsic layout where it just works.