First off: The minmax(0, 1fr) thing in grid columns blew my mind. 🤯 I actually was using flex for like forever, but almost a year ago I came to the same conclusion. Grid is just so much more predictable in so many use cases and it is so much more versatile. There are so many layouts you can do with with grid, without the need of wrapping it into like 50 flex-containers first.
Right, it's them gazillion divs you sometimes need for flex that's always putting me off. Only short of as bad as float layouts. And you're right: grid's more predictable once you get your head around it.
I believe it was from Rachel Andrew's book "The New CSS Layout" that mentions this specific point. Use flexbox when you care about how content is distributed in one direction (row or column). Use grid if you care about how content is distributed in a two dimensional area (row and column).
I go a step further than this. I prefer using grid even for one dimension, it just feels more predictable, and you can avoid the issues I described in this video. I only use flexbox when I need wrapping.
I love you guys so much! In fact, I had the exact same question a week ago, and I had to resort to JS evil hacks to avoid a layout shift, so I'm super glad this video was made :)
I got in the habit of using the "flex hammer" for everything because I was waiting on good support for grid for a long time. I'm glad prefixed flex is not a thing anymore.
I prefer grid for named template columns which makes changing the entire layout for different screen sizes really easy. Hadn't thought about this added bonus. Really great as always!
Even tho this is true, I feel like the streaming of HTML is not really representative of the real world, as network frames are usually larger, which can still be a problem for very long html. But the main issue is making the layout dependent on the content (as said), but Images still the biggest UX offender in the layout shift problem.
HTTP203 : you know that thing you loved and excited to learn? - don't use that! I kid of-course, excellent video as always Jake and Surma and everyone else involved in creating this!
I never knew about the minmax(0, 1fr) thing! Or at least, didn't remember it strongly. Great episode Another big gotcha with grid layout for me was learning that 1fr is actually minmax(auto, 1fr), and not minmax(0, 1fr). It feels like that default was chosen for the grid use-case of quite flat content, e.g. items in a shopping menu, rather than entire page layouts. Because for the latter case (which is where i most often find myself using grid, you instead want to exactly define the boundaries, and not let the content inside shift the grid.
This is a really interesting point. A lot of the newer intrinsic layouts that we use for intrinsic web design are, I guess, going to have this problem with layout shift if we're not careful. But ultimately, I still think intrinsic layouts are better, because we're laying out all of the page based on the content. I'd be interested to hear Adam Argyle's thoughts.
Using inline styles in the HTML to define css variables for a local component is a great idea. Bummer about CSP doors it requires to be opened to use it.
That's one of the great advantages over server side vars in Sass or Less which are static. You can also use JS to modify or insert CSS vars and use them as live, dynamic hooks and proxies between the JS part (logic and computing) and the layout.
I prefer flexbox (when appropriate) because it's faster to write and that's most important for my job. We have so many services to develop that we can't spend any time on a comparatively insignificant detail like page layout, what's important is quick development so we can push out the required functionality in time. That said I do see a reason to care about this if you're developing something for the mass-market and making it feel fluid is important to drive engagement.
even when I worked on a project with similar pacing, quite a few times I had a situation where I'm writing something with flexbox, can't fix a small layout bug for hours, angrily rewrite it to grid and it works from the first try. Don't recall having the opposite problem
"insignificant detail like page layout" that's a true data dev speaking. If all you do is apps and little smart components displaying some random horing numbers and data chunks then this might be ok. For a site that actually has large content articles like a news website, magazines or even blogs, page layout is THE utter most significant thing CSS has to provide. Luckily the it can serve both purposes but people tend to believe their line of work is what the web is all about. In either case it isn't.
@@CirTap True. For context most of the web applications we make are digital forms to replace physical paper forms. They have no images aside from icons and for the most part a simple vertical layout, without support for anything aside from Chrome desktop because it's only used by our own employees. Most apps have like a dozen blocks of CSS at most (the majority have 1-2 blocks) because everything is a custom component, so all we use styles for are to set some margins, align content, etc. Everything loads slowly, looks ugly, but it's still miles ahead of paper forms. And the priority lies in replacing more paper forms, not polish existing forms to improve user experience.
@@emilemil1 Sounds like grid-template-areas can solve a lot of your repetitive form structures. Plus, there's also column property for simple stuffs. Flexbox, on the surface, looks simple but most of the time I help people, they're confused about the nitty-gritty details of flexbox like flex-basis, flex-grow, and justify-content/align-items (they don't understand why one is suffixed with content another one is items). Once you got the basics of grid/inline-grid, everything will be a breeze. Bonus: you can force-stack elements without absolute positioning. Another bonus: gap support for grid is much higher than flexbox.
I would really like to see an HTTP 203 episode of modern layout, but with overflow. This has always been an issue for me on the web. Like an element with dynamic height, but overflow when reaching 100vh, I just solve it with wrapping grid content in a div and put absolute positioning (which feels very much like a hack...). Otherwise, great topic! I think as devs we need to put a lot more focus on preventing CLS
Ah, good ol' layout shifts. This is where the new skeleton loading UX pattern comes in handy. Sometimes changing from flex to grid is not viable, and other times grid will cause shifts too (when using auto)
👏🏾 Excellent!! Will be using this discussion to inspire/encourage the team to venture out a bit of their flexbox reliance. (I can imagine them now talking about support 😜 blah blah)
I'm out of the loop of web development because reasons, but... What about responsive layout? Do we still need a bunch of media queries and repetition? I did like that I could avoid that with flex (to be fair we have CSS preprocesors). Also, does contain-instrinsic-size help with the columns problem or not?
With flexbox or some clever usage of grid's auti-fit and auti-fill in repeat() you can often avoid media queries if you're fine with giving up on pixel perfect layout and DO allow the content and device constraints do their thing. If you're trying to fight your content and CSS you usually loose -- or at least have a miserable experience. 😇
From my understanding you want to avoid a style tag as it can cause the browser to re evaluate the layout, so better to use a class to define the columns. Although it is readable using custom props inline.
Sorry I meant the attribute. Derp. I remember this having large performance issues in the past. Due to the parser seeing new styles and having to recalculate. Maybe this is different for custom properties. Using a stylesheet and classes I thought was preferred.
@@xjdesigns if you use the style attribute you can easily get specificity issues cos nothing beats that. That's why classes and BEM in particular are less prone to this, given you understand the cascade and inheritance that makes CSS so powerful in the first place.
@@CirTap that is a great point. Just remember importance is more specific that style attributes and I believe the :global. BEM is just a naming convention but I use all the time.
@@xjdesigns an advantage and the idea of BEM is to use flat (and elongated) classnames that don't compete in specificity, and they can give you semantics whereas Framework usually throw semantics out the window. You don't actually do long nested selectors if you adhere to BEM, at least that's one of the ideas. But that usually goes down the drain if you work with a prprocessor, where selectors eventually get out of hand once transpiled into native CSS. They long flat classnames of BEM's *methodology* actually honour and work with the cascade if done right. Not sure what you mean with :global as there is no such keyword in vanilla CSS. There's :root (and other :-ish selectors) and as a pseudo element has the same specificity as a vanilla .class
great content. Thanks. Need some info on lazy load html elements section based on intersection oberserver api. Please let me know. will this impact CLS of that page.
I now understand why I found flexbox weird. But I don't understand why I didn't find grid weird if `1fr=minmax(min-content, 1fr)`. Still a bit puzzled.
I created a grid layout and found it super simple and completed my work much faster but found some difference in iPhone on any browser where a blue low-opacity circle gets automatically added in the background. The other elements inside my grid columns are text, link, div layer with box shadow, and ofcourse the image. Is anyone aware of how this occurs? If any of these elements creates a background automatically?
I DID THE SAME THING WITH THE GRID COLUMN ROW THING... I'm not sure who made the decision to have "flex-direction: row" align things the same as "grid-auto-flow: column". Smh my head.
I wonder why I can't use "data-*"-attributes for the repeat-mechanic. If I give my HTML data-cols="3" and use in CSS grid-template-columns: repeat(attr(data-cols), 1fr);, that's not working out. But I can use the attr(data-cols) for other CSS-mechanics like "content: attr(data-cols)". Why doesn't it work for "repeat"?
I guess because data-* attributes are parsed as text in CSS and the first argument for repeat() is an integer. There may be a proposal to have browsers type cast to integers in the future.
I was under the impression that flex: N 0 0 was fine for layout? I've been using basically that mixed with flex: none for an electron app UI and other than some dumb edge cases like scrolling requiring min-height: 0 and the like it's worked really well? The main thing I found was it's a lot harder to just toss some elements and stock classes and get a layout with grid, I always needed to be pulling out a custom grid layout. Maybe I should look into it more?
I don’t think the argument is not to use it but it is or was (at the time of the article) not as performant. I would add, and the article mentioned says the same thing, that the advice is targeted towards when you have lots of content and or a slow connection the layout has to start over. From the article mentioned: "Flexbox is great, it just isn't the best thing for overall page layouts." In my experience, if you are running or thinking you are going to run into performance issues that you do some testing on the devices that your target audience will use. Once you create your project for your client have the client test it. Optimize after that or if you know it will be a big project optimize ahead of time with advice mentioned in this video. Whatever the case run tests yourself and see.
@@jakearchibald right, I meant more specifically the later conversation about how you shouldn't use flex for layout anyway since it is more complicated to use than grid and it will size to min-content, which can cause reflow on content changes. Obviously in am electron app or even an SPA (which is pretty much everything I do in html) I'm not too concerned about streaming content.
@@SimonBuchanNz right, but in a JS heavy app you've got the issue of layout being impacted by changing content. Proper grid usage protects you from this.
@@jakearchibald that was basically my question, aren't you protected by the flex-basis: 0? Or did I get confused and you also need min-(height|width): 0 too? Or is that still not enough?
First off: The minmax(0, 1fr) thing in grid columns blew my mind. 🤯
I actually was using flex for like forever, but almost a year ago I came to the same conclusion. Grid is just so much more predictable in so many use cases and it is so much more versatile.
There are so many layouts you can do with with grid, without the need of wrapping it into like 50 flex-containers first.
Right, it's them gazillion divs you sometimes need for flex that's always putting me off. Only short of as bad as float layouts. And you're right: grid's more predictable once you get your head around it.
I believe it was from Rachel Andrew's book "The New CSS Layout" that mentions this specific point. Use flexbox when you care about how content is distributed in one direction (row or column). Use grid if you care about how content is distributed in a two dimensional area (row and column).
That's her mantra in virtually any of her talks about grid and layouts over the past five years. She's a brilliant teacher and tech writer.
I go a step further than this. I prefer using grid even for one dimension, it just feels more predictable, and you can avoid the issues I described in this video. I only use flexbox when I need wrapping.
If you have a static size (like 25em), you can wrap with grid too! Just do grid-template-columns: repeat(auto-fill, 25em)
@@__mayank if you've got a static size you can just use floats 😀
Good way to think about it
I love you guys so much! In fact, I had the exact same question a week ago, and I had to resort to JS evil hacks to avoid a layout shift, so I'm super glad this video was made :)
I got in the habit of using the "flex hammer" for everything because I was waiting on good support for grid for a long time. I'm glad prefixed flex is not a thing anymore.
I prefer grid for named template columns which makes changing the entire layout for different screen sizes really easy. Hadn't thought about this added bonus. Really great as always!
Even tho this is true, I feel like the streaming of HTML is not really representative of the real world, as network frames are usually larger, which can still be a problem for very long html. But the main issue is making the layout dependent on the content (as said), but Images still the biggest UX offender in the layout shift problem.
HTTP203 : you know that thing you loved and excited to learn? - don't use that!
I kid of-course, excellent video as always Jake and Surma and everyone else involved in creating this!
I never knew about the minmax(0, 1fr) thing! Or at least, didn't remember it strongly. Great episode
Another big gotcha with grid layout for me was learning that 1fr is actually minmax(auto, 1fr), and not minmax(0, 1fr).
It feels like that default was chosen for the grid use-case of quite flat content, e.g. items in a shopping menu, rather than entire page layouts. Because for the latter case (which is where i most often find myself using grid, you instead want to exactly define the boundaries, and not let the content inside shift the grid.
This is a really interesting point. A lot of the newer intrinsic layouts that we use for intrinsic web design are, I guess, going to have this problem with layout shift if we're not careful. But ultimately, I still think intrinsic layouts are better, because we're laying out all of the page based on the content. I'd be interested to hear Adam Argyle's thoughts.
Using inline styles in the HTML to define css variables for a local component is a great idea. Bummer about CSP doors it requires to be opened to use it.
That's one of the great advantages over server side vars in Sass or Less which are static. You can also use JS to modify or insert CSS vars and use them as live, dynamic hooks and proxies between the JS part (logic and computing) and the layout.
Loving all the IKEA furniture
I like how the two presenters are the ears of the face that scene portrays.
I prefer flexbox (when appropriate) because it's faster to write and that's most important for my job. We have so many services to develop that we can't spend any time on a comparatively insignificant detail like page layout, what's important is quick development so we can push out the required functionality in time.
That said I do see a reason to care about this if you're developing something for the mass-market and making it feel fluid is important to drive engagement.
even when I worked on a project with similar pacing, quite a few times I had a situation where I'm writing something with flexbox, can't fix a small layout bug for hours, angrily rewrite it to grid and it works from the first try. Don't recall having the opposite problem
"insignificant detail like page layout" that's a true data dev speaking. If all you do is apps and little smart components displaying some random horing numbers and data chunks then this might be ok. For a site that actually has large content articles like a news website, magazines or even blogs, page layout is THE utter most significant thing CSS has to provide. Luckily the it can serve both purposes but people tend to believe their line of work is what the web is all about.
In either case it isn't.
@@staskrul5531 that's exactly my experience. I've had "why the **** is it doing that???" experiences with flexbox way more than grid
@@CirTap True. For context most of the web applications we make are digital forms to replace physical paper forms. They have no images aside from icons and for the most part a simple vertical layout, without support for anything aside from Chrome desktop because it's only used by our own employees. Most apps have like a dozen blocks of CSS at most (the majority have 1-2 blocks) because everything is a custom component, so all we use styles for are to set some margins, align content, etc.
Everything loads slowly, looks ugly, but it's still miles ahead of paper forms. And the priority lies in replacing more paper forms, not polish existing forms to improve user experience.
@@emilemil1 Sounds like grid-template-areas can solve a lot of your repetitive form structures. Plus, there's also column property for simple stuffs. Flexbox, on the surface, looks simple but most of the time I help people, they're confused about the nitty-gritty details of flexbox like flex-basis, flex-grow, and justify-content/align-items (they don't understand why one is suffixed with content another one is items). Once you got the basics of grid/inline-grid, everything will be a breeze. Bonus: you can force-stack elements without absolute positioning. Another bonus: gap support for grid is much higher than flexbox.
Good stuff. More CSS Please!
I got layout flashbacks from this
I would really like to see an HTTP 203 episode of modern layout, but with overflow. This has always been an issue for me on the web. Like an element with dynamic height, but overflow when reaching 100vh, I just solve it with wrapping grid content in a div and put absolute positioning (which feels very much like a hack...).
Otherwise, great topic! I think as devs we need to put a lot more focus on preventing CLS
Ah, good ol' layout shifts. This is where the new skeleton loading UX pattern comes in handy. Sometimes changing from flex to grid is not viable, and other times grid will cause shifts too (when using auto)
CSS is the King, JS is queen, CWV are future of SEO
👏🏾 Excellent!! Will be using this discussion to inspire/encourage the team to venture out a bit of their flexbox reliance. (I can imagine them now talking about support 😜 blah blah)
Can't wait when can drop supporting Chrome 49 on XP and use grid for layout.
1fr in grid-template-columns blew my mind... 0.o
"everything looks like a nail when you have a hammer" - Every new development tool, framework or spec 😄
I'm out of the loop of web development because reasons, but... What about responsive layout? Do we still need a bunch of media queries and repetition? I did like that I could avoid that with flex (to be fair we have CSS preprocesors). Also, does contain-instrinsic-size help with the columns problem or not?
Good point. Instead of --columns, maybe it should have been --items, which the CSS could turn into however many columns depending on the layout.
With flexbox or some clever usage of grid's auti-fit and auti-fill in repeat() you can often avoid media queries if you're fine with giving up on pixel perfect layout and DO allow the content and device constraints do their thing. If you're trying to fight your content and CSS you usually loose -- or at least have a miserable experience. 😇
I absolutely agree 100%
nah, I have the same opnion about only using flexbox for when grid cannot do something
How about a guide on using a switch controller as a powerpoint clicker?
nice course
From my understanding you want to avoid a style tag as it can cause the browser to re evaluate the layout, so better to use a class to define the columns. Although it is readable using custom props inline.
Nah, that isn't true. A style tag is just as likely to cause a layout as a style attribute.
Sorry I meant the attribute. Derp. I remember this having large performance issues in the past. Due to the parser seeing new styles and having to recalculate. Maybe this is different for custom properties.
Using a stylesheet and classes I thought was preferred.
@@xjdesigns if you use the style attribute you can easily get specificity issues cos nothing beats that. That's why classes and BEM in particular are less prone to this, given you understand the cascade and inheritance that makes CSS so powerful in the first place.
@@CirTap that is a great point. Just remember importance is more specific that style attributes and I believe the :global.
BEM is just a naming convention but I use all the time.
@@xjdesigns an advantage and the idea of BEM is to use flat (and elongated) classnames that don't compete in specificity, and they can give you semantics whereas Framework usually throw semantics out the window. You don't actually do long nested selectors if you adhere to BEM, at least that's one of the ideas. But that usually goes down the drain if you work with a prprocessor, where selectors eventually get out of hand once transpiled into native CSS.
They long flat classnames of BEM's *methodology* actually honour and work with the cascade if done right.
Not sure what you mean with :global as there is no such keyword in vanilla CSS. There's :root (and other :-ish selectors) and as a pseudo element has the same specificity as a vanilla .class
great content. Thanks. Need some info on lazy load html elements section based on intersection oberserver api. Please let me know. will this impact CLS of that page.
It will if the layout shifts as a result. Elements appearing is fine. Elements shifting around is bad.
I now understand why I found flexbox weird. But I don't understand why I didn't find grid weird if `1fr=minmax(min-content, 1fr)`. Still a bit puzzled.
I created a grid layout and found it super simple and completed my work much faster but found some difference in iPhone on any browser where a blue low-opacity circle gets automatically added in the background. The other elements inside my grid columns are text, link, div layer with box shadow, and ofcourse the image. Is anyone aware of how this occurs? If any of these elements creates a background automatically?
Note: not sure why this does not happen on Android phones but I've checked across iphones se, and x and many Android phones
I DID THE SAME THING WITH THE GRID COLUMN ROW THING... I'm not sure who made the decision to have "flex-direction: row" align things the same as "grid-auto-flow: column". Smh my head.
Awesome
is that a joycon controller?
I wonder why I can't use "data-*"-attributes for the repeat-mechanic. If I give my HTML data-cols="3" and use in CSS grid-template-columns: repeat(attr(data-cols), 1fr);, that's not working out. But I can use the attr(data-cols) for other CSS-mechanics like "content: attr(data-cols)". Why doesn't it work for "repeat"?
I guess because data-* attributes are parsed as text in CSS and the first argument for repeat() is an integer.
There may be a proposal to have browsers type cast to integers in the future.
I was under the impression that flex: N 0 0 was fine for layout? I've been using basically that mixed with flex: none for an electron app UI and other than some dumb edge cases like scrolling requiring min-height: 0 and the like it's worked really well?
The main thing I found was it's a lot harder to just toss some elements and stock classes and get a layout with grid, I always needed to be pulling out a custom grid layout. Maybe I should look into it more?
I don’t think the argument is not to use it but it is or was (at the time of the article) not as performant.
I would add, and the article mentioned says the same thing, that the advice is targeted towards when you have lots of content and or a slow connection the layout has to start over.
From the article mentioned: "Flexbox is great, it just isn't the best thing for overall page layouts."
In my experience, if you are running or thinking you are going to run into performance issues that you do some testing on the devices that your target audience will use. Once you create your project for your client have the client test it. Optimize after that or if you know it will be a big project optimize ahead of time with advice mentioned in this video. Whatever the case run tests yourself and see.
flex: N 0 0 has the same problem as the first grid example in the video
@@jakearchibald right, I meant more specifically the later conversation about how you shouldn't use flex for layout anyway since it is more complicated to use than grid and it will size to min-content, which can cause reflow on content changes. Obviously in am electron app or even an SPA (which is pretty much everything I do in html) I'm not too concerned about streaming content.
@@SimonBuchanNz right, but in a JS heavy app you've got the issue of layout being impacted by changing content. Proper grid usage protects you from this.
@@jakearchibald that was basically my question, aren't you protected by the flex-basis: 0? Or did I get confused and you also need min-(height|width): 0 too? Or is that still not enough?
is that a switch controller??
Avoid all nonsense by making your pages Netscape compatable, HTML 2.0 standard, ONLY.
display: inline-box; width: 30%;
I thought you were leading to columns: 3
😂
Hello World!
I gotta know how Jake uses Nintendo Switch joycon for his notes 😏
Hello dunia internet,, salam dari aceh🤝🤝👌👌
Wait are they using a Switch JoyCon as a clicker 😂
Yep! It works with Chrome as a bluetooth gamepad.
@@jakearchibald thanks to you I discovered Gamepad API and my sleep will suffer for that. Also thanks for responding and for the great content 👍
@@iamwlad8533 Same here.
Js...
#ءشگme
Can we please just throw CSS away and use Dart/Flutter in combination with SKIA/Webassembly?