The future of CSS layouts: a new unified approach

Key Takeaways

Hello my front-end friends and welcome to my podcast general musings. My name is Kevin and in this podcast I talk about whatever is front of mind for me in any given week usually in some way that's related to front-end development. And this week we will definitely be talking about front-end development specifically about CSS and the future of CSS layout potentially maybe and the unification of flexbox and grid sort of maybe not quite but going in that directionish. Yeah, there interesting times right now with the debates that are going on just with layout in general when it comes to CSS and my I have some thoughts on it that are somewhat concrete but not completely concrete and I find it really helps for me when I think out loud and so we're doing a podcast episode where I get to do that and try and figure out what I actually think about all of this and the whole reason this discussion has come up is because Safari or not Safari the WebKit team has put out a blog blog post titled item flow part one, a new unified concept for layout. And it's interesting. It's this idea that um it's sort of come from all this discussion over masonry where there's obviously some disagreement on the best approach for implementing masonry. And a lot of the introduction to this article just gives that backstory. But this I'm going to read this paragraph here where it says a lot has happened since October and that's when the October is brought up because that's when there was the competing ideas sort of came up between just use grid or this new masonry layout. And so for some context on that, just in case you haven't been following all of this discussion, Safari is behind the just use grid where you'd have a grid template columns or a grid template rows of masonry, whereas Chrome thinks there should be a display masonry uh that's separate. And nobody's winning right now. And winning is the wrong word there, but just it seems to be like people that are in one camp or in one camp, people that are in the other camp are in the other one. And then a lot of other people like me sort of go back and forth every time we hear certain arguments. Oh yeah, that makes sense. I think that one's better. And then the other side will be like, well, what about this? And you're like, oh yeah, that's right. Maybe that would be the better approach. And I think what that this discussion has been really good in that it's highlighted that there's issues potentially with either one of the approaches. And so here, I'll start this paragraph again. A lot has happened since October. Now a third path forward is emerging. a path that would mean the CSS working group doesn't choose either just use grid or new masonry layout. It merges ideas from both with a completely new idea to create a unified system of item flow properties. This article explains what item flow is and the impact on both flexbox and grid. And then they're going to have a part two article that talks specifically about masonry. And so the main idea here isn't to drop flexbox and grid and make one CSS layout thing, but it's to have properties that work for both of them. Sort of like we have gap, right? So when gap first came, it was grid gap and we could only do gaps and grid actually came from CSS columns. That's where gap originated, but they brought it into grid. We had the grid gap property and then eventually that got brought to flexbox as well. And then we dropped grid gap and then we just have gap and we have it in both of them. And the idea here is can we use this for other things as well which is interesting and it's a lot of these item specific things. So one of the examples uh they give is uh for item direction or item wrap. Uh the item wrap one I'm not 100% behind the argument that they give in in the WebKit article because um they talk about so with item wrap the idea would be it replaces or it doesn't I well I guess it would replace it would replace uh flex wrap cuz you could use item wrap no wrap or item wrap wrap and you have the reverse and work exactly the same way but you'd be using item wrap but then with the item wrap you'd also be able to use it in grid and the example they of is that instead of doing the I'm trying to remember the property and I I don't want to scroll up and down this entire time. Oh, here it is. Uh so it would be to replace oh the grid autoflow. So if you do a grid autoflow of column, it's basically like saying no wrap, right? It's sort of like you're creating columns and they're never going to wrap. And they say like I'm going to read this. What if you want to lay out all your content in one row when using grid but instead of each item gets the same amount of space uh so for every item to be one fr wide since the size of the column is exttrinsically determined CSS grid is the right tool for the job but because grid wraps by default developers often hack flexbox instead not realizing they can get the desired effect today from grid autoflow column and I'm just like well yeah but then just use grid autoflow column I don't know like it's not our fault that people don't know that certain things exist. I love grid autoflow column, but at the same time, I also understand that if there was this unified approach that that just makes it easier cuz then you you just know item wrap no wrap and it's going to prevent wrapping. Um, but you'd also have to already have switched the flow direction with grid, I think, right? Or maybe you're using the repeat syntax. Like, I don't know. I I I I don't quite wrap my mind around how that would work in that situation with grid. Um but it doesn't really matter too much. Um there's a few Anyway, there's a few other properties, too. There's things like item pack that would be a completely new thing that I think a lot of people would like. There's some good visuals to explain how it works. Um that deal with like making things fit a little bit better. Uh there's also I'm trying to oh there's the yeah the item pack balance I think is what people would really like which is I've seen a lot of people asking for this. So right now with flexbox if you have wrapping you might have like five items across the top and then one item wraps to the bottom and then that one item stretches the entire size. So the idea there is we could do they're saying item pack. The names for all of these are up for debate, but it would be item pack balance. And then when the wrapping occurs, it's actually going to balance the number of items that are on the two rows that are being created a little bit. I guess like a text wrap balance, that type of idea. And that 100% I could get behind having something like that. Um I I don't know exactly how that would you work or with um grid though, cuz grid sort of already works that way. But anyway, there there's different ideas that are out there. Um, and one of they they have a nice chart in it that sort of goes if we use this, this is how things would change or or function instead of how they currently do. And I think there's a lot of good ideas that are being brought up in here. And I think the idea of a unified system where we have more similarity between them, even if the behavior between the two isn't exactly the same, if it's similar, developers are going to like that because I really do feel that a lot of developers learn either flexbox or grid. They become comfortable flexbox or grid and they don't use the other one cuz it feels like it's just this completely other system. And so if we could make something that's a little bit more unified that works in a little bit more of a similar way, I think that could be really beneficial. It does lead to me wondering like could all of this be done just with like a new display property and everything grouped together. Uh but I think that might be opening too big of a can of worms and um yeah, I'm not 100% sure there. I I think the one the one issue still would be that there's probably going to be certain properties or not properties certain values for properties that work a bit different between the flexbox and grid version and they'll have to just cuz they're two different layout modes. Whenever there's inconsistencies like that, people get a little bit frustrated. I had been talking bit about this in my newsletter recently as well just about the CSS mindset where when you go into different layout modes so display flex display grid even position when you change your position to an absolute or a fixed or whatever you're changing the layout mode for that element that the algorithm changes and so like even like a width 1,00 pixels isn't a width 1,000 pixels all the time right you declare that it should just always be that but then you do a display in inline and the width doesn't do anything and you do a display flex and it might be a,000 pixels But it or if the parent has a display flex, the child might be 1,000 pixels or it might be smaller cuz it might be squishing with the flex shrink on there. So like depending on the situation, things are always going to be a little bit different and it makes sense most of the time why they're a little bit different. But um yeah, I think it's the right idea, but I'm just worried that people are still going to complain about the inconsistencies. But I think that if I think this is one of those things that a browser is going to once again have to put into um production, not production production um but like behind a flag or just in the technical preview/ canary or whatever just so we can actually play with it. And I'm curious if now that web kit team has put this out, I'm curious if they're actually going to start prototyping this or not. uh just like everything else is being prototyped with all of these proposals because I think this is something that we need to play with to see if it's actually a good idea because in theory I think will be very different from actually using them. Uh a few interesting things that have also come up through all of this has been the there there's one property called the proposal for it was item slack which I really didn't like. I I I'll read what it says. The item slack property would allow you to control just how picky the layout engine is when determining where to put the next item. For masonry style layouts, this would be the new name for the property previously discussed as grid slack or masonry slack. A default slack of 1 M means, hey, when you're looking to see which column has an empty space closest to the top as you decide where to put the next item, don't worry about it if the difference is 1 m or less. Just consider those tied. For flexbox, this could be a point from which loose packing to cramming is an extra one uh to cramming in an extra item which is currently set to zero. A value of 1 m would mean if it's within 1 m of fitting, cram it in, otherwise wrap it to the next line. With flex wrap, this would be fantastic, right? Like right now, items with flex wrap only wrap when they get to like as small as possible. So, if we could have like some cushioning there where it would actually wrap a little bit earlier before it gets to everything's hitting those minimum sizes, that would be really nice. Um, and they actually the CSS working group opened an issue just on the naming specifically for item slack. And I think or it actually it has been resolved. They're going to change the name to item tolerance. So, um, if you go and check it out, they talked about that. And I think tolerance is a much better name than slack just because not even as I one of the points brought up was non-English speakers the word item slack like it it the slack might not be easy to interpret even as a native English speaker like I had to read that to understand it and I didn't feel like slack was great. So the tolerance I think is a much better name. So we're sort of saying, okay, we can tolerate a a 1 m or 1 ram or 10 pixels or whatever it is difference as you're sort of dealing with these types of things. I think that makes a lot of sense. The other thing that has come up through all of this though actually and in that same working group issue, it did come up that during the previous discussions there's talk of changing them from item everything. So like if I get the list here, um item direction, item wrap, item pack, item slack, item flow, which is a short hand that it potentially would be flow. So flow direction, flow wrap, flow pack, flow tolerance, I guess. Uh and when I first read that, I didn't like it. And now that I'm saying it out loud, I think it actually makes more sense. So we'll see about that then. Uh yeah, I think the flow actually does make a lot of sense there, especially flow direction instead of item direction. And then the flow wrap is you want it to the flow wrap no wrap flow wrap reverse things like that make sense. Flow pack normal flow packing are we densely is everything densely packed or not. That's a really interesting idea and I'm sort of behind that now. Yeah. Now that I've said these words out loud and this is why I like talking them out loud cuz sometimes when it's just in your head um it doesn't quite sound the same. So yeah, that that's kind of interesting with that. The other thing that I found was or there is a working group issue on this that I've commented on, but it's for a generic layout item flow controls. So, this everything we're talking about here, it's actually in the working draft. No. Uh, yeah, this is a working draft for CSS. I'm going to have to let me just click on that flow control. We're good. Uh, for grid layout module 3. So, uh, I'll put a link to this also in the show notes. And it talks about the this idea of having these item properties which I guess potentially could be flow properties. And it was tab atkins posted in the GitHub issues about potential other naming convention which instead of item direction would be item track. Instead of item wrap would be item cross instead of item pack. Item pack would stay the same and item slack. So it was mostly item direction becoming item track and item wrap becoming item cross. And the idea here is to make the properties more semantically meaningful from what I understand. Um, and just there's some nuance a little bit between focusing on like the direction of the items versus the track the items are on. And then with item wrap versus item cross, the idea is like we're talking about how they're working on the crossaxis. And because like you can do an item wrap reverse isn't really talking about wrapping cuz we're putting things reversed and we're not talking about it's actually like a no wrap reverse, right? So, uh there's a little bit of a naming thing there where maybe item wrap or or the flex wrap probably maybe wasn't the best name to begin with and this is a chance to correct that. And that's a little bit how I see that argument coming from and maybe I'm wrong on that. um where tab was coming from on that. But my I put I I I I commented on this in the GitHub issue talking about how the problem with renaming them to new things like item track and item cross or so we said flow track and flow cross maybe um is that we as developers have already understood things like item wrap because we have flex wrap. we have years of using flex wrap and then to throw item cross in there I'm super worried people are just going to be like what what the heck is this and that rather and you know 10 years down the line maybe we're never using flex wrap because we don't have to cuz we have this other property so like new developers aren't going to come with this baggage but every current developer has the baggage of what we're used to using and I think we need to lean into that if we're trying to make something more unified that people are going to adopt and start using that we need it to be as familiar as possible to what they're already used to. uh just because like already now I've had multiple people tell me that they've tried to use logical properties in at work and they've put in their pull request and the pull request has been denied because they used a logical property because the person looking at it didn't know what it was and they said well nobody on the team is going to know what it is so just use the regular property instead and you're just like oh I if people aren't or if people are getting their poll requests denied because they're using a logical property. Imagine if item cross showed up all of a sudden, right? Um, and like obviously we have new things like the item slack or tolerance or whatever. There will be new things coming along with all of this that we will have to learn. But I just think if there's a familiar if it's replacing a current existing thing where the existing thing doesn't change like flex wrap is if you use item wrap and you use flex wrap within the flex context they would be literally interchangeable with one another. Having two different completely different names there to me adds a level of friction for the adoption of that feature. So that's one thing um that I'm curious about and how it yeah where that's going to go that part of the discussion and it's something I'm definitely following. The other thing that I think it was Andy Bell brought up on blue sky was the part with this where part of the discussion maybe we're going in the wrong direction right now or not the wrong direction. And I think this is a really important topic that should be discussed, but we need to be a little bit careful in that we want to make sure that if this gets implemented, how are we dealing with the just the reordering of things? Because even with this, I believe even if you're using flexbox, there's the potential of rearranging items outside of the regular order. And definitely with masonry, that would become a big thing. We already have that with grid if you use dense, right, where things can be out of order. Um, and this is something that Rachel Andrew brought up. I think it was at CSS day where she went over a little bit of the grid versus masonry debate, but then transitioned over to talking about tab ordering and potential for the having something in CSS that could fix when we muck around with order. And I really wish this was getting more traction. And maybe I should do my own part because I have a platform. So, this is part of it. Let's let's start here and now that I'm saying this is why I like the podcast. It gives me an opportunity to ramble and talk out loud and makes me realize things that I probably should have already realized. Um, so I think I will bring more attention to that. But when we pull things out of order and then if tab orders get mucked up because of that, it just can ruin user experiences or make them very awkward at the very least. And so there's this idea that maybe there's something we can do that allows the browser, and this would be a lot of work probably for the browser, but I guess maybe not. I don't know. But it allows the browser to modify the tab order to become visual. So as soon as the things are out of order, if you're as long as you haven't changed tab indexes on anything, that it would follow a logical ordering. And I don't know how the browser would figure out what logical would mean in terms I guess there' be have to be a lot of talk and and figuring out of that because there's probably some edge cases where it would be very hard to determine what actually makes more sense. But um yeah, if we're giving users this possibility of rearranging stuff in the masonry layout would definitely make this happen in in how it's being proposed and and working right now that if things are going out of order, how are we dealing with that? Cuz this is going to encourage people to place things out of order. And so I do think before that gets implemented, we should probably have a mechanism that deals with that. And so that I'm surprised hasn't been getting more attention. So yeah, let let's start talking about that a little bit more. If I can find any I haven't even looked for it. I've been thinking about it a lot and I haven't looked for it, but I'm going to look for um anything I I'll put links to anything in the description I can find on that that can help just spread spread word on that and make that part of part of the discussion. And maybe I'll start planning a YouTube video on it as well uh for the main channel. But yeah, it's interesting time for CSS right now. And that I think this the idea here too with this item thing and this unified layout is like okay, if we do this properly, we can add masonry in without any overly new ways of doing things. Like we don't maybe we don't need to reinvent everything as much as we thought. And it would potentially also open up to being like, okay, this would also work in this other imaginary world of something we haven't thought of yet where we'd still be able to use these types of things within this other context. Um, you know, maybe I don't know where CSS is going with it, but as I don't know, with 3D and and other things coming in, maybe it would potentially come in with like AR stuff. I don't know. I have no idea at all. But u just some I think that's sort of the idea is like let's stop making a whole bunch of different stuff and try and just have find the similarities between things and and see how we can make those work. So, it's interesting times. Anyway, I'm curious to see where this goes. It's definitely something I'm keeping a very close eye on. So, if there's any major progressions in this, I'll do another post on it and talk about what I think about where things are headed. Uh I said post, but you know what I mean, right? Uh but yeah, I think that's it for this week. So, thank you very much for listening. if you did enjoy it. Well, I I'm assuming you did if you're still here listening. So, thank you uh for for listening and thank you for enjoying it. That doesn't sound right. Uh I'm glad you enjoyed it. That sounds a little bit better. And of course, until next time, don't forget to make your corner of the internet just a little bit more awesome.