You will find her name quite often when you research CSS grids - she's something of a layout and grid expert. If you'd like to read more, check out some of her fantastic posts at Smashing Magazine, where she's chief editor: https://www.smashingmagazine.com/author/rachel-andrew/
I’ll bite. In my experience, almost every case where CSS Grid has been touted as enabling something new was actually already possible with flexbox alone. Care to share your UI pattern that I gather uses Grid and Flexbox, and I’ll see if I can reasonably reproduce it without Grid?
Basically, a list of items arranged in a grid where the number of columns is dynamic depending on the width, items are wrapped dynamically from left to right, each column consumes the maximum amount of space, there's a fixed gap between columns, and the last row is aligned left, not stretched. I had to build one recently, and it was a perfect fit for grid.
Cannot this be done with just floats or inline-blocks and percentage width? Unlike grid, it would work in a larger number of browsers.
Also, I think that tutorials for things like flexbox or grid should include fallbacks for older browsers. Because generally frontend devs simply copy the code from tutorial so if you don't include the fallback, they won't implement it.
But then it's responsive to the page size, not the container size. That's a small, but important difference.
For instance, I recently made a component to be included on other pages at work. It had to look good no matter the size the page gave it. So they might put it into a 400px wide container, on a 1600px wide page. If I used vw or media queries to draw it based on page size, it would behave wrong.
I was thinking about that problem earlier. Is there not a CSS unit for container size? If not, that seems like a very useful addition. Like a more embedded version of vw/vh.
AFAIK every browser but IE11 supports the modern basic grid syntax. Edge has supported the new syntax since Edge 16 which is old enough to be widely deployed in enterprise now. So as far as I'm concerned that's the "Vast majority of browsers" and for static grids I just use the old syntax as a fallback for IE11
The support for grid is very good for the vast majority of modern applications[1], given its power and the things it can simplify that often require JS solutions otherwise
You can reproduce a fair bit of Grid using just Flexbox (and we did that for quite a while before Grid came along)—but it's going to be far more verbose, both your HTML and CSS, and probably more brittle and complicated to change.
If you're setting precise sizes in flexbox, or very specific flex values, you're probably in Grid territory. Ideally, flexbox is best when you want things to stretch/shrink to fit and you want the items to determine their own sizes. Grid is best when you have a specific layout/sizes in mind, and you want to impose that layout onto the items.
A horizontal list, where each item has variable width based on its content. Inside each item there is additional hidden content, which should factor also into the item width. The hidden content should display behind the primary content.
When hovered, the hidden content will appear via an animated dropdown. The height of the content varies as well.
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])
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)
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.
That'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.
But 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.
But here’s the thing: Grid’s regular handling of long terms is typically not actually ideal anyway.
Grid is just the layout (columns/rows), not entirely how text is handled. 3 & 4 are no different with grid, only word-break/word-wrap with forced/limited widths.
And 1 & 2 seem disjointed and hard to read (ie, break long held rules for readability), I don't see the value arbitrary space after the key. 1 & 2 would easily be better suited to this:
Key:
Value, even on
multiple lines
A long key:
Value, even
on multiple
lines
Or this:
Key: Value, even on
multiple lines
A long key: Value, even
on multiple lines
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...
Used to draw round corners [the biggest design trend request circa 2002] using tables with cells of one pixel, painting every cell mimicking a perfect anti-aliased curve in a photoshop rectangle, a mere 32 cell table per corner, lol.
That takes the cake. The worst I did was 9 cells, with images in each corner. How did you maintain your sanity when one cell went bonkers on it's dimensions for no good reason?
Your comment made me remember that every cell had a blank gif so the dimensions would be exact! Even found a wiki about it https://en.wikipedia.org/wiki/Spacer_GIF
Yep, an image was the only way to "guarantee" the cell displayed at a specific width/height. These are the kinds of things that taught me most hacks aren't worth doing.
ha, 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.
Of 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.
There was a time when the only way to get nice 1px borders was to place your table inside the other table, set the outer table's cell to the color you wanted for your background and then set cellspacing on the inner table to 1px.
That’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.
np, glad I could help. I avoided grid for a long time until I read way too many good comments about it not to dig in a bit until I was convinced as well.
If 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.
Unfortunately 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.
That 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?
Its 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.
It 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.
I actually think grid is simpler. The flex properties are confusing and make common cases complicated. Grid fits my mental model of what I am trying to achieve pretty much 1:1.
Grid doesn’t really use a new type of element either.
I’m just happy to be able to layout things 2D in a way that isn’t totally bonkers and do weird contrived calculations to make everything fit in the viewport. My only wish remaining is a unit that is like fr for grid layout but can be the same value for both row and grid (so an equivalent to vmin for viewport)
Though both are used for laying out your content, but Grid and Flexbox serve different purposes though. We can probably still use Flexbox for majority of the cases, but Grid was designed to help with some specific CSS layout problems that only it could resolve.
Mixing the two is very useful. I typically make headers and footers with flex, build home page grids with grid, and then use flex to space out content in the cells.
No more floats, no more percent widths, no more weird nth child tweaks for positioning.
Add rems to the mix and responsive design has never been simpler. For grids you can just change from say a 3 column grid to a single column on mobile for most cases.
I feel like flexbox was such a savior already that I'm still comfortable there.