Anyone becoming a front end web developer today has no idea what we used to have to go through in order to simply put content on a webpage where it needed to go. Forget about having it scale responsively to screen size and orientation, much less — we were happy when the header, footer and main sections stayed at the top, bottom and middle.
Gather children, and listen how we forced HTML table markup to do layout duty (oooohhh scary!) and then, with CSS, we got to fight with floats and positioning and hacked-together workarounds like clearfix (screams of terror). For the longest time, it was ridiculously difficult to simply place elements on a page: layout tools simply didn’t exist, or were woefully primitive. Finally, at long last and a mere two decades after the first web browser was introduced, we got the CSS Flexible Box Layout and CSS Grid Layout.
Flexbox, as the first is widely called, became viable in mid-2016 when it was finally supported in all current versions of every major browser. It is a remarkably powerful and, well, flexible layout tool that makes it possible to change the placement, dimension, and direction of elements. Everything from nav links to images to, yes, tables can be quite easily arranged — and, with media queries, rearranged — regardless of original size and even (how cool is this?!) HTML markup order.
Hot on the heels of Flexbox came Grid, which is on the verge of complete browser support <makes slant eyes at Opera Mini>. Grid introduces more new features giving devs the power to intelligently size and place elements inside a “grid container” that itself automatically adapts to available space. This supports responsive design and makes it easier to create layouts that work in a variety of different browser sizes, without the use of those pesky media queries.
Flexbox and Grid actually share many of the same capabilities, which appears to be a source of confusion for developers eager to take advantage of them. In some cases, Flexbox is the right thing to use, in others Grid, and sometimes a combination of the two is best. But how to know when to use what?
The easiest way to frame the Flex vs. Grid dilemma is to think in terms of dimension.
At the most basic level, Flexbox is intended for arranging elements in one-dimensional situations — i.e., individual items in a row or a column. It is more of a micro-level tool for placing multiple related items local to a parent container: Nav items in a header, buttons inside a form.
Grid, on the other hand, is intended for more macro layout purposes. Mainly, arranging larger container elements on the page: the header, the main, the footer.
I say “intended” here because Flex and Grid can often be used to solve the same problem, each in their own way. Indeed, before Grid came along, devs were happily using FlexBox to create page placement. The core difference between the two is that Flexbox is rooted in content, while Grid is oriented to page architecture. Let’s get right to the code so you can see what I mean.
Here is the markup for an extremely basic navigation element:
Before applying any Flexbox properties, the nav items appear in markup order as block elements, i.e., one on top of the next:
(N.B.: There are some styles being applied too, obviously, but since they don’t pertain to Flex or Grid we are just going to leave them out of our discussion, ‘k?)
Once we activate Flexbox with the “display: flex;” property/value pair, however, the list items will line themselves up in a nice row, sharing the same line:
Looks pretty great already, with a single line of Flexbox! If, however, we would like them spaced evenly in their parent container, we can add “justify-content: space-around;” and the list items obediently distribute themselves vis-a-vis each other and the available space:
The beauty of Flexbox is, beyond the minimal code requirement, that the items will always maintain the same proportional distance between themselves regardless of screen width! Talk about responsive.
Getting on the Grid
Flexbox excels when it comes to adjusting the placement of elements within a parent container – the combination of flex-parent and flex-child properties is truly powerful in terms of adaptability to just about any situation. As flexible a tool as Flexbox may be, however, it is still something of a blunt instrument when applied to broader page architecture, where stability and precision are of the utmost concern.
In short, Grid’s greatest value is the same as its greatest pain in the ass: precision.
Grid can be used to distribute the same nav items in the same exact orientation. However, because it is not really intended for this kind of more precise, smaller-scale (“micro”) placement of content, there is a lot more code required to achieve the same exact effect. Beyond going from four lines of CSS to a dozen, we also had to go into the markup to call out individual list item elements by putting an id on each, and then placing them precisely within the established grid:
The One-Two Punch
On their own, Flex and Grid are both powerful when used appropriately in their areas of strength (and, importantly, with appropriate semantic markup)…When we combine them, however, we unleash all kinds of heretofore untapped layout powers!
Let’s put together a simple website layout that is, honestly, the exact architecture that many many sites boil down to when all the flashy stuff is stripped away: a header, a footer, a main content area, plus a side area because wtf not:
The markup is ridiculously spare and the CSS for placing these elements using Grid is also gloriously minimal:
Look at that! An entire web page’s basic architecture, sketched out in six lines of HTML and 17 lines of CSS, all thanks to Grid…and some tactical use of semantic HTML5.
Now let’s throw a little Flexbox in there to flesh out the navigation, using our code from above:
We simply turned the header element, which is itself a grid item, into a flex parent so that we could apply Flexbox properties to the content inside of it!
Our exercise above was a bit forced, but the point is to show that Flexbox does some things well, things that Grid can also do too — just with a lot more code. And vice versa. So there are definite situations where Flexbox is called for, other situations better suited to Grid… and times when both used together in the proper context can be a symphony of elegantly minimal code.
So the tl: dr of how to choose when to use Flexbox vs. Grid in a given situation is,:
- Use Flexbox for one-dimensional (i.e., in a column or in a row, not a grid) arrangement of elements in a container. Benefits are less code and responsive adjusting of the elements vis-a-vis each other inside the parent container.
- Use Grid for broader, macro page layout of large container elements or divs. Benefits are extreme precision in placement and the ability to overlap elements when needed.
- Use Both together for complex layouts: Grid to create the architecture, and then Flexbox for placement of smaller pieces of content inside the larger semantic elements.
Feature image via Pixabay.