8 ms·
I would suggest finding a single use for grid that flexbox doesn't really do well, and use only a couple properties. Then you will really understand the benefit
by Vanderson 7y ago
I would suggest finding a single use for grid that flexbox doesn't really do well, and use only a couple properties. Then you will really understand the benefit of grid without having to invest a lot of time.
An example I dealt with recently: I needed a header with logo / external link / social icons/ content / phone link. All to layout perfectly, and be mobile friendly.
With grid, I used this: (this is rough code to demonstrate the simplicity, I made a codepen demonstrating it properly. [0])
header {
display: grid;
grid-template-areas:
"logo content link social"
"logo content phone phone";
}
For each of the logo, content, etc... areas you use this to attach it to the specific location in the grid.
.logo {
grid-area: logo;
}
.content {
grid-area: content;
}
etc...
You end up with exactly what you would expect:
+------+---------+-------+--------+
| | | link | social |
+ logo + content +-------+--------+
| | | phone |
+------+---------+-------+--------+
For mobile, I wanted this:
+---------------+
| Logo |
+---------------+
| Content |
+------+--------+
| Link | Social |
+------+--------+
| Phone |
+---------------+
Here's the only CSS needed for mobile. (or reverse this if you are doing mobile first layout)
@media (mobile) {
header {
grid-template-areas:
"logo logo"
"content content"
"link social"
"phone phone";
}
}
Here's the html:
<header>
<div class="logo" ></div>
<div class="content"></div>
<div class="link" ></div>
<div class="social" ></div>
<div class="phone" ></div>
</header>
The power to move content around with such simple and clean code like this is amazing.
With flexbox you can use the "order" property to move stuff around a little, but not control the exact layout so cleanly and simply. There are tweaks for adjusting the widths of columns and heights of rows, but this is generally all that is needed to get the layout with grid.
There is also grid-gap [1], something not possible in flexbox yet. (though Firefox supports grid-gap with flexbox)
[1] https://codepen.io/Vanderson/pen/yWWVVZ https://codepen.io/Vanderson/pen/yWWVVZ
[1] https://developer.mozilla.org/en-US/docs/Web/CSS/gap https://developer.mozilla.org/en-US/docs/Web/CSS/gap
- pbhjpbhj 7y agohttps://caniuse.com/#feat=css-grid https://caniuse.com/#feat=css-grid (92% of users)
- baroffoos 7y agoThe trap is CSS grid in IE which is counted as partially supported is a much older spec of css grid which works quite different to the final spec.
- naniwaduni 7y agoStill 90% even without IE, though.
- Vanderson 7y agoIf you _have_ to support IE, I would just add conditional comments, and make all grid stuff one column and not worry about fancy stuff. IE users just can't expect the internet to pander to an outdated and unsupported browser. If it was supported by MS, I might consider a little more care though.
- baroffoos 7y agoUnfortunately the website I work on has more users on IE than any other browser. I wish I could use grid but there is just no point when the fallback would be the main way to see the website.
- Vanderson 7y agoThat is a rare circumstance, and I agree with your assessment, no point in making life hard for yourself. Since IE is no longer supported (or even considered a browser by MS, but a compatibility layer) what kind of site do you work on that is so heavily trafficked by primarily IE?
- baroffoos 7y agoIts a project management web app. For some reason every IT department seems to have locked all the computers they manage to only running IE, and then they customize the shit out the settings on IE which make the site break in insane ways that we can't test.
- dmix 7y agoThat’s awesome. That’s a very common problem even for non layouts. Many of the complex UI elements I work on daily all need basic mobile support where I could see applications for this. It seems to be about a mix of grids with flux instead of either/or.
- Vanderson 7y agoI've found grid to be helpful even with just rows of data, no columns, using grid-gap to make space between rows, like in a standardized form. But you are right, something like a gallery of images (unknown number of items that need to flow), flex seems more useful.
- duxup 7y agoThanks man that is awesome. You are right that I just haven't NEEDED it and without that I don't tend to grock things.
- runarberg 7y agoIn my experience the prime example of something that works better using grid then flexbox is with description lists `<dl>`: dl { align-items: baseline; display: grid; grid-gap: 1.5ex 1.5em; grid-template-columns: fit-content(12ch) 1fr; } dl dt { font-weight: 600; grid-column: 1; } dl dd { grid-column: 2; } This will put all your terms in the first column and all your descriptions in the second. All aligned nicely and creates a new row even if you have two `<dt>`s or `<dd>`s in a row. A flex solution would quickly fail once the terms get irregular. https://codepen.io/anon/pen/gJJmzM?&editable=true https://codepen.io/anon/pen/gJJmzM?&editable=true
- Vanderson 7y agoThat's clever. I think it's easy to make complicated solutions, and this is pretty clean. I like the solution for irregular content/tags getting displayed correctly.
- chrismorgan 7y agoBut here’s the thing: Grid’s regular handling of long terms is typically not actually ideal anyway. Here are four ways of formatting such lists: ① Something that can be achieved with float, fancy margins or a couple of other related techniques (with caveats, inside this markup structure, such as needing both dd and dt to be inline, since `display: run-in` died): Key: Value, even on multiple lines A long key: Value, even on multiple lines ② A flex approach: Key: Value, even on multiple lines A long key: Value, even on multiple lines ③ A grid approach, avoiding wrapping keys: Key: Value, even on multiple lines A long key: Value, even on multiple lines ④ A grid approach, wrapping keys (and you’d better hope the key is wrappable): Key: Value, even on multiple lines A long Value, even on key: multiple lines Now as it stands, your fit-content approach lands part-way between ③ and ④, wrapping the terms where possible, but extending the column’s width if necessary (e.g. if you use a long, unbreakable word, which experience tells me will be a URL and thus insanely long). Yet I would argue that in most cases of unknown content, ① or ② are better, most commonly ①. Wrapping terms is generally a bad idea (especially if there is no border in the grid), and if arbitrary content can end up in the term you’re likely to get pathological cases, like URLs in the term. (I say all this as one who switched his known-content-that-doesn’t-trigger-these-cases <dl>s to `display: grid` over a year ago. But for arbitrary user content, I’d be more likely to go back to approximating ①, probably with markup other than <dl> now as well, to avoid problems related to it.) This approach to handling outliers (break out of a rigid grid, wrap, extend all, &c.) is worth thinking more about. In the article this thread is about, I am actually not convinced that having the card internal elements lining up is a good thing. Here’s the problem: the depiction of its appearance when they don’t line up is deceptive, and not how you would realistically implement it. Without subgrid, you’d be using `display: flex; flex-direction: column` on the cards, and that’s what’s depicted; but what the depiction lacks is `flex: 1` on the content, so that the header and footer take the least space possible, rather than themselves flexing as well. If you fix that, the not-lining-up case no longer looks terrible; I’d say that at that size then it’s six of one, half a dozen of the other; and for larger grids or more pathological cases, it’ll very arguably be nicer.
- tyre 7y agoWow this is incredible. Thank you for the example; much easier to understand the value right away
- Vanderson 7y agoIt took me probably a day of testing to convince myself because I really didn't find a simple example. I have simple atomic classes that create a set of columns I use frequently that solve problems that just a few years ago were always an annoying mess. Grid requires no/fewer wrapping elements, solid outcomes (ie, code matches result more often than other layout methods from the start) and lots of minor properties for edge use cases. And this is just a summary of the benefits.
- chrisweekly 7y agoWonderful comment, bravo! I think back to the early days (circa 2000 or so), before CSS positioning and float hacks were even a thing, working as the lead webdev at Upromise, meticulously hand-crafting complex layouts with nested HTML tables... you could nest them 5 or 6 levels deep before running into noticeable render performance issues in what must have been, what, IE4 and NN4? It really has been a couple decades, hasn't it. Kinda wish every FE dev had to follow the path the industry took to get where we are now... /ramble
- Vanderson 7y agoha, ah the memories. On my first web job (late 90s) my boss interviewed a guy who was bragging about one pixel borders around an element that were all background colored table cells. (each had to have an image in them to force the cell size, remember doing that?) I knew how to do this, but I said it just wasn't worth doing. I think this is how web tech works best, when you see the best way coming down the pipe, don't waste time on hacks. But I admit, floating was the only way to make columns for far to long. I know grid is taking a long time to take root. I primarily only use grid-template-columns, grid-gap and areas or really only needed for major/complicated layout.
- wolco 7y agoFloat? Why not table with inline width=95%/align=center
- Vanderson 7y agoOf course back in the day we all used tables, but there was a shift where "tables=bad" for layout, but we didn't have a good replacement yet... so it was floats.
- maaaats 7y agofloat, with "faux columns" that I copied from a-list-apart for every new page I made.
- emp_ 7y ago