 we film a few of these in a row and I know I know spoiling the magic. I know I've clearly gone away from the studio, slept and come back for another day in these jeans. But that means that this episode now is probably going to be like 12 weeks into the future. Yeah. What do you think the world's going to be like then? Like because it feels like we're on the cusp of a change right now. For the worse? Well, that's the question, isn't it? So what I'm going to talk about, some of this. Columns with content. Columns with content. So imagine you needed to do this. You wanted to do this three equal columns, like with a gap in between them. There's a few ways of doing that now. Like we've got a variety of different layout, block layout, grid layout, flex layout. They will all do the trick. Exactly. So I wanted to look at a couple of ways of doing it. That look kind of similar. So got this one. Yeah, display grid, all columns, flow, whatever, gap. And then there's this one. Do you even need the other flow? Oh, I can't remember. It's one of those. Do you know what? With this and flex, I always just put it in because I can never remember what the default is. So I just tap it, tap it, tap it. There we go. So there's two things here. And I have sometimes gone for the first one over the second one, because it feels more versatile. Doesn't the second one have three columns? Well, yes. And you would have noticed in the first slide, there were three columns. Yes. Sorry. For some reason, I read columns as like, oh, they have to go horizontally. You're thinking of rows, mate. Yeah, that's true. But yeah, the first one, you could have as many columns as you want, right? It just sort of figures stuff out. But I think the second one is the right choice. Second one? Yeah. And it's to do with how, partially how to do with the browser, how the browser passes content and what happens while the content is loading. So say we've got this back to our divs from before. Yeah. So the next hiding broke? No, deliberately, because I'm going to introduce this in character by character. And the top half is going to be what the parser receives. And the bottom half is going to be what the parser creates. The DOM that emerges from yes. Okay. Exactly. So because the browsers can create DOM while they're downloading HTML. Mm-hmm. So we start off. Nothing. Nothing. Nothing happening at this point. You know why? I mean, you know why. I do. I actually, I don't know why. If I know why, I have a hunch. Got it? There we go. Yeah, there we go. And that's when the parser goes, right, okay, we've got a div. I know what all the attributes are. And this is the point, it will go and create that element and stick it on the page. We don't have an n tag yet, but we do in the DOM because there's not such a thing as an n tag in the DOM. That's just the visual representation of a DOM. The node exists. The node, it exists. And the pointer is inside that node. Because as we create more stuff, we've just added some white space. But nothing else has changed. But once again, we haven't created an element yet because we haven't reached it. And on we go, we've now got a div inside that div. And so on and so on. We start adding content. More divs appear. So you end up with a situation where, as the page is downloading, these divs can appear one by one. A lot of it depends on the speed of the connection, what else is going on. But that is where we see the difference between these two bits of layout. Because this one will load in like this. There we go. Whereas this one will load in like this. Now, which one is better, Jake? The first one was better, wasn't it? Yeah. I was actually going to argue that I like this better. Not in terms of how it loaded in, but the way I declared it. Because it doesn't tie me to a specific layout. If I wanted to add a column, I can just add it in the markup. And that is a nice developer experience. But this is another example of where developer experience comes at the cost of the good user experience. Exactly. And it's easy to see some content like this to go, well, is the browser really going to render it halfway through? I mean, it can. That's the thing. You can say, well, probably not. Thing has crossed. That tends to be a bad way to develop software. Literally, before we start doing this episode, I was reading an article on my phone on good internets here in the office. And there was a tweet embed that wasn't loading very fast, and it moved the entire page in a weird, awkward, meaningless state almost. And that was probably down to JavaScript this time. But that could happen here as well. Like one of those columns could be added later with JavaScript. If your middle column has a lot of content, which is usually the column which does, then there's more chance of the browser doing a mid rendering. It won't be quite busy until it gets to the end of the middle column node, and then there's the right node, and then suddenly everything gets squished, which is also an expensive layout if the middle column is big. So absolutely, it adds up. And also, if you have a streaming template in language, which sounds like a fancy term, but what I really mean is PHP, if you do a database lookup in the middle of that column, then there's a point where you're going to add more milliseconds of server time. And it will encourage the browser to flush and render. And this is the kind of thing that you're not going to see on your local development environment. It's a real gotcha that you really need to turn all of the settings down to the minimum just to see this happen. And it doesn't mean someone will have to be on that slow connection or to see it, because it comes down to chance, which is a problem. But as you say, this is something that people will, they'll avoid doing this for the reason you said, like, oh, I don't want to specify three columns. Because what if I have another layout that has four columns, I'm going to have to do another class, a whole other thing. And like, however many columns you're going to have, I'm going to have columns two, columns three, columns four. When I could just have one, that seemed to work fine. I would say that the workaround for that would be to do something like this. Props, props, props, props. Because at this point, you probably know how many columns you're going to have. And grid has repeat. So this is literally grid has repeat. There we go. There's very little arguments we made that this is in any way worse. Yeah. And I think some people would see the inline style and go, inline style is bad, but we're using it in a semantic way this time. So even if you're against it in terms of inline styling, we are using it more in a semantic way here. And I think this kind of gets you the best of both worlds, gets you that reusable class. But yeah, it gets you that nice rendering as well. If you want really badly, you could make your build system generate that style tech for you. So you don't have to count yourself. Absolutely. Yeah. Because three, I mean, I mean, with a react, I guess, you've got to get past one and two before you get to three. Yeah. I mean, but I guess with, you know, react, preact components, that's actually quite easy to do. You know your children, you can literally count them and add that number to an inline style that it might actually be quite, you don't even need a proper build system. Yeah. So, and I can see this happening if you've got like a series of menu items, like horizontal menu items, where like if you're an admin, it's got two more. But by the time you're creating that element, you've got the thing, no, is admin or I know how many things are going to create, I'll add that number in. I would say grid, if you're using grid template columns, doesn't mean that you've solved this problem. No. Because there are values you can put in grid template columns that do depend on the content. And that's really what we're talking about here. The difference is, is the layout being defined by the CSS or is it being defined by the CSS plus the content plus the HTML. And where when you're saying, you know, 1fr, 1fr, 1fr, that's the CSS saying there is going to be three columns here. Whereas if the auto version, it's like, I don't know, let's see what's in there. And that's when you create the layout problems. But here we've got some values, max content, min content, auto fit content, auto and fit content just derived from max content and min content in various ways. And it creates that problem here because it's essentially saying, I want this column to be related to what's in it. Yeah. And sometimes that's okay, especially if it's the first column because it doesn't matter so much. But if it's the last column, then you're still going to have that thing where everything's wide and then the last thing comes in, it doesn't know how wide it's going to be until it's there. And this is also what they mean that both grid and I think also flex are multi-pass layouts because what they give you can depend on the element's intrinsic size, as it's called. And that sometimes means that it has to start over because now that it knows the intrinsic size of a last element, it actually affects all the first couple elements need to be laid out to make it all work and it has to start over. And then maybe it wasn't the last element, another one comes and it has to start all over again, which makes it sound really bad. It's not like you should use grid, you should use flex. Absolutely. But it's something to be mindful of and that they have these capabilities just opens up a whole a bunch of new problems that we need to care about. I'd like to talk more about flex, but first here's a here's an interesting fact that I didn't know. What does 1fr mean? That I was literally contemplating whether I should ask because I was thinking about it if one, if repeat 3 1fr actually is always a three column layout of equal size because I don't think it is in all cases. I was trying to remember because 1fr means for it's the free space and you can distribute the free space with these weights. So if you have 1fr, 1fr, 1fr everyone gets one third of the free space. If you do 2 1 1 the first one gets twice as much as the other two. But it's free space. And so I was wondering if the that basically is how much space is left after I lay out the elements with their intrinsic size, I guess. So if I and text I think can be squished to almost any arbitrary size. So it's not a good example with images, for example. I wonder if it will be different. You're kind of right. You're kind of right. So here's the deal. Although it does matter with text. So here we've got three equal columns because we've got 1fr. But whoop, this happens. So now that first column has to be that size because it can't wrap that text because it's all one word. And now it's become bigger and the other two have had to squash as a result. And it's not down to the free space distribution. It's down to a very, very weird edge case in how 1fr is defined. Because 1fr means they should be the same size, but 1fr doesn't mean 1fr when it's in grid template columns or in repeat. What 1fr actually means is min content 1fr. Oh, really? Yeah. How it's really weird. When I saw this, it sort of blew my mind because you could put zero in there in which case it does this. If you wanted to have actual equal spacing, we just use calc 100 divided by number of columns. Okay. So the difference between 1fr and percentages is that if you use percentages, then the gap is going to add to that. You would have to manually deduct the gaps. I would have to deduct the gap. You're right. Whereas with fr, it's the fraction after the gaps. Also, does 1fr actually stand for free space? Fraction. Fraction, but okay. So it actually doesn't have anything with the available space. After all, it's literally the space that is being laid out. It's a fraction of that group, with the exception of it being min content. I misunderstood something. Your definition is very close to Flexbox, I'd say. Probably, yeah. Which we should probably talk about, because it is entirely content driven. There's no way of defining your flexing up front. Like, it's always going to be driven by content. And this makes it... Better and worse. But it's, yes. Okay. It's bad for page layout. Yeah. Because it's always going to have that layout issue. If you're doing any kind of flexing within your Flexbox, and if you're not while you're using it, you are going to end up with this issue, or the potential of this issue, where things shift around as they load. In some ways, table layout can be better. Because table layout is a grid, right? Yeah. And you can use... I mean, even in IE8, you can use divs, but you use CSS to give them table-like properties. Yeah. And you can use fixed table layouts to say, right, whatever the first row is, that's going to be fixed for the rest. And you can get a more stable render than you can with Flexbox, the much newer layout system. It's got to the point where I only use Flexbox for things that grid cannot do. And those things do exist. Yeah. Wrapping. Yeah. Multiple rows where the rows are independently laid out. Because page are supposed to not look like a grid. Yeah, grid is very much... Grid is very much... Yeah, grid is the two-dimensional layout. And sometimes if you've got a set of sponsor logos or something that have different sizes and you want them to be centered and have a gap between them horizontally and vertically, but you don't want them necessarily in a grid, you just want them horizontally. A horizontal masonry layout. Yeah. There's a good Flexbox thing, right? Yeah. That's what Flexbox is for. And it'll be interesting to see how the comments for this video go. Because I'm telling people, don't use Flexbox for your page layout. Use grid because it's better at this. It has these better layout semantics. Because all of this content that I've just been talking about, this is old content because I wrote this in 2014. And people got very angry about it. I'll put a link to this in the description. Go and have a look at the comments. People are telling me I know nothing about anything and I'm stupid and I should be sad and ashamed. They're not wrong, but about this, they are wrong. I am stupid and should be ashamed, but not for this. Because when I wrote this, I had talked to... I'd come up with this theory. Well, this seems bad for all the reasons I've talked about. And I asked them, is this right? Oh, yeah, yeah, yeah. Flexbox is bad for this. We need grid. But I guess in 2014, the story on grid was very different because it barely existed. I guess it was the time where we had a V1 of grids, or the V0 or whatever in IE, and nobody else had anything. So it's... It's exactly that. It was only in IE at the time. And this blog post, the example's not work anymore because it was based on the old... IE grid examples. And the reason I wrote this post to make the case for grid is because at the time, browsers were dragging their heels a little bit around the grid implementation because we'd done Flexbox not that long before. And I think the perception was, look, people have been dealing with floats forever for a decade. And we've just given them a new layout system. Come on, that must be good for another 10 years or something. So this was really my case for like, no, this is not good for this. And I think people were getting angry because they were like, yeah, but it's so much better than what we had. I'm like, yeah, yeah, but we need something. Everything starts to look like a nail when you have a hammer. Yep. So this whole episode is just like, I think you'll find I was right. Or maybe I'm not. Maybe the comments are going to be like, no, you stole wrong, Jake. Shut up. We're going to continue to use Flexbox. I was going to just say, the first time I've seen posted on the 5th of February, 2014, only five months after the previous post. That's pretty much the cadence. Coming up to like a 10 year anniversary of it. I like that you added only, it's only five months. Yeah, pretty good going. I'm going to hit the 10 year anniversary of this, you know, my blog soon. And it's like, yep, 11 posts or whatever. It's pretty much the same cadence as our podcast. Pretty much. Subscribe to our podcast. Can I talk about that? This could be completely tone deaf by the time it goes out. It could be. That's as with all of our episodes. It could be terrible by the time it goes out. It probably is.