One of the highest ideals of web design is that a website’s content (e.g., its text and images) and the manner in which that content is presented (e.g., how it’s styled and arranged on the screen) should be kept separate. Practically speaking, this means that HTML should structure the content and give it semantic meaning but HTML should not do anything to determine the content’s layout and appearance. Any layout and appearance — any presentation — should be handled by CSS.
CSS’s arrival in the late ‘90s and its subsequent maturation have made that ideal increasingly attainable, with sites like CSS Zen Garden revealing what’s possible when content and presentation are kept separate. Website code becomes cleaner and easier to develop and maintain because the HTML isn’t mucked up with layout information (e.g.,
<font> tags, inline styles) and it’s even possible (in theory) to completely redesign a site without touching the underlying HTML.
CSS is now an indispensable part of modern web design (and rightfully so) but content and presentation aren’t nearly as separate as we might like to think they are. In the dark ages, we used HTML tables and single-pixel spacer GIFs (a terrible combination of content and presentation) before moving on to CSS floats and various positioning tricks. Then flexbox emerged and became widely supported, and all seemed right with the world. Flexbox is certainly fantastic — if you’re not using it, you really should be — and it got us further down the path to true content/presentation separation, but it can still be hampered by one aspect of HTML: source order, or the order in which HTML tags appear in the source code.
Consider this very basic webpage markup:
<div class="wrapper"> <header> Page header (logo, nav) goes here </header> <div class="sidebar sidebar-A"> Sidebar A content goes here </div> <div class="content"> Page content goes here </div> <div class="sidebar sidebar-B"> Sidebar B content goes here </div> <footer> Page footer (nav, copyright and contact info) goes here </footer> </div>
Now, let’s say that you want to accomplish the following layouts using the above HTML:
- On mobile/tablet, both “sidebar”
<div>elements should display after the “content”
<header>element should display between the “sidebar”
<footer>elements. (So that the content is the most visually prominent element on the page.)
- On laptop/desktop, the “sidebar” and “content”
<div>elements should be sandwiched between the
<footer>elements. The “sidebar-A”
<div>should be on the left of the “content”
<div>and the “sidebar-B”
<div>should be on its right. (In other words, your basic three-column “holy grail” layout.)
Flexbox can do a lot of cool stuff, but even with its considerable power, the above source order represents a hurdle to realizing both scenarios. You could wrap the “sidebar” and “content”
<div> elements inside another
<div> element, but that adds complexity to the markup and complicates the DOM a bit. Furthermore, doing so may make other layouts difficult to achieve because of the additional nesting. More likely, you’ll need to compromise your design goals and go with a different layout for at least one of the above scenarios.
Enter CSS Grid Layout. To be clear, this is not the same thing as the CSS-based grids that come with frameworks like Bootstrap and Foundation. Rather, it’s a still-under-development addition to the official CSS spec. The best definition of Grid Layout comes from Rachel Andrew, one of Grid Layout’s biggest evangelists. She writes:
Grid Layout lets us properly separate the order of elements in the source from their visual presentation. As a designer this means you are free to change the location of page elements as is best for your layout at different breakpoints and not need to compromise a sensible structured document for your responsive design.
Essentially, Grid Layout turns a
<div> into a grid with a specific number of rows and columns. We can then “assign” its child elements to specific coordinates on that grid. What’s more, we can create different grid layouts and assignments for different breakpoints using media queries (just like we do with everything else). And all of this is completely separated from how the content is ordered and organized in the source code.
Going back to the code block above, we could rearrange the HTML however we wanted and it would not affect what the webpage’s visitors see. All presentation would be determined by the CSS; nothing is determined by the HTML. As Patrick Brosset puts it (emphasis mine):
CSS Grids allow you to optimize the markup for accessibility without compromising your ability to manipulate the visual result. One other point is that the markup will be somewhat lighter and easier to understand, and therefore easier to maintain.
But more importantly, this gives a very powerful tool for separating the content from the layout, effectively decoupling them in a way that making a change to any of them doesn’t impact and otherwise break the other.
As a designer, you could easily experiment with new layouts without having to change anything else than CSS, as long as your new layouts provide the expected lines and areas the content uses. And as a developer, you would simply need to use the numbered or named lines and areas to position your content on the grid.
That’s a very beautiful thing.
If this still doesn’t make much sense, then I recommend watching this presentation that Andrew gave at the 2015 CSS Day conference:
The first time I watched Andrew’s presentation, I got chills because I knew I was seeing the future of front-end web development. This is how it should be… how it should’ve always been.
There are some caveats, of course. Since Grid Layout is still being developed and defined, “official” browser support is negligible:
- Chrome/Firefox/Opera: You need to enable Grid Layout via hidden browser flags. (It’s supposedly supported by the recently released Chrome 50, but I still needed the browser flag after updating.)
- Safari: Only supported in the Safari Technology Preview and Webkit Nightly builds with a “-webkit” prefix.
- Edge/IE: An older version of the spec is supported by Edge and IE 10/11, but only with the “-ms” prefix. Edge should begin supporting Grid Layout’s current version soon.
But even with browser support lacking, Grid Layout’s future is bright. So far, there doesn’t seem to be the same convoluted-ness that surrounded flexbox (and which led to three different versions of the flexbox spec) — which is an encouraging sign.
Since the Grid Layout spec isn’t finalized, that means there’s time to learn about it and be ahead of the curve — and there are plenty of resources to get you started. By far the best that I’ve found is Andrew’s own Grid by Example site. It has plenty of well-documented examples of the spec’s intricacies that show off its power and flexibility. Andrew’s blog is also a good source of Grid Layout info.
I realize this post’s title may seem over-the-top. But when you start working with Grid Layout and see what can be done with it — and believe me, what I’ve described here barely scratches the surface — you’ll wonder how we ever got as far as we have to date with our current methods for building websites (flexbox included).