CSS Grid!Published 6 years, 3 months past
The Grid code is coming! The Grid code is coming! It’s really, finally coming to a browser near you! Woohooooo!
Whoa, there. What’s all the hubbub, bub?
CSS Grid is going to become supported-by-default in Chrome and Firefox in March of 2017. Specifically, Mozilla will ship it in Firefox 52, scheduled for March 7th. Due to the timing of their making Grid enabled-by-default in Chrome Canary, it appears Google will ship it in Chrome 57, scheduled for March 14th. In each case, once the support is enabled by default in the public-release channels — that is to say, the “evergreen” browser releases that the general public uses — every bit of Grid support now in place in the developer editions of the browsers will become exposed in the public releases. Anything Grid will Just Start Working™®©.
Are those dates an ironclad guarantee?
Heck no. Surprise problems could cause a pushback to a later release. The release schedule could shift. The sun could explode. But we know the browsers already have running code for Grid, and when they mark something as ready for public release, it usually gets released to the public on schedule.
So Grid support in March, huh?
How long until I can actually use Grid, then? Two or three years?
March 2017. So about four months from now.
But it won’t be universally supported then!
Rounded corners aren’t universally supported even now, but I bet you’ve used them.
Now you’re just being disingenuous.
Look, I get it. Base layout’s a little different than shaving pixels off corners, it’s true. If you have a huge IE9 user base, converting everything to Grid, and only Grid, might be a bit much. But I’m guessing that you do have a layout that functions in older browsers, yes?
Then my original answer stands: March 2017. Because any browsers that understand Grid will also understand
@supports(), and you can use that to have a Grid layout for Grid-enabled browsers while still feeding a float-and-inline-block layout to browsers that don’t understand Grid. Jen Simmons wrote a comprehensive article about
@supports(), and I wrote a short article demonstrating its use to add layout enhancements. The same principles will apply with Grid: you can set up downlevel rules, and then encapsulate the hot new rules in
@supports(). You can retroactively enhance the layouts you already have, or take that approach with any new designs.
Writing two different layouts for the same page doesn’t sound like a good use of my time.
I get that too. Look at it this way: at some point, you’re going to have to learn Grid. Why not learn it on the job, experimenting with layouts you already understand and know how you want to have behave, instead of having to set aside extra time to learn it in a vacuum using example files that have nothing to do with your work? You’ll be able to take it at your own pace, build up a new set of instincts, and future-proof your work.
Can’t I just wait until someone creates a framework for me?
You could, except here’s the thing: as Jen Simmons has observed, Grid is a framework. Using a framework to abstract a framework seems inefficient at best. I mean, sure, people are going to do it. There will be Gridstraps and GAMLs and 1280.gses and what have you. And when those are out, if you decide to use one, you’ll have spend time and energy learning how it works. I recommend investing that time in learning Grid Actual, so that you can build your own layouts and not be constrained by the assumptions that are inevitably baked into frameworks.
Grid sounds like tables 2.0. I thought we all agreed tables for layout were a bad idea.
We agreed table markup for layout was a bad idea, particularly because at the time it was popular, it required massive structural hacks just to get borders around boxes, never mind rounded corners. The objection was that it took 50KB of HTML tags and three server calls just to do anything, and 100 times that to set up a whole page’s layout, plus table markup locked everything into a very precise source order that played merry hell with any concept of accessible, searchable content. The objection wasn’t to the visual result. It was to what it took to get those results.
With Grid, you get the ability to take simple, accessible markup, and lay it out pretty much however you want. You can put the last element in the source first in layout, for example. You can switch a couple of adjacent bits of the page. Questions like “how do I order these elements to get them to lay out right?” become a thing of the past. You order them properly, and then lay them out. It’s the closest we’ve ever gotten to a clean separation between structure and presentation.
Not only that, but thanks to CSS transforms, clipping paths, float shapes, and more, you don’t have to make everything into a perfectly-edged grid layout. There is so much room for visual creativity, you can’t even imagine. I can’t even imagine. Nobody can.
So Grid solves every single layout question we’ve ever had, huh? Layout Nerdvana for all?
Oh, no, there are still things missing. Subgrid didn’t make it into these releases, so there will still be some gridlike layouts that seem like they should be simple, but will actually be difficult or impossible. You can’t style a grid cell or area directly; you have to have a markup element of some sort to hang there and style. All grid areas and cells have to be rectangular — you can’t have an L-shaped area, for example. Grid gaps (“gutters”) can only be of uniform size on a given axis, very much like
border-spacing in table CSS.
You can usually fake your way around these limitations, but they’re still limitations, at least for now. And yeah, there will probably be bugs found. If not bugs, probably unexpected use cases that the spec doesn’t adequately cover. But a lot of people have worked really hard over an extended period of time on stamping out bugs and supporting a variety of use cases. This is solid work, and it’s going to ship in that state.
What happens if Firefox or Chrome pushes Grid back a release or two, but the other ships on schedule?
In that case, it will take a little longer for your
@supports()-encapsulated Grid rules to be recognized by the tardy browser. No big deal. The same applies to MS Edge, which hasn’t caught up to the new Grid syntax even though it was the first to ship a Grid implementation — with different rules, all behind prefixes. Once Edge gets wise to the new syntax and behaviors, your CSS will just start working there, same as it did in Firefox and Chrome and any other browser that adds Grid.
All right, so where can I go to learn how to use it?
There are several good resources, with more coming online even now. Here are just a few:
- The Experimental Layout Lab of Jen Simmons — great for seeing layout examples in action using a variety of new technologies. If you’re laser-focused on just Grid, then start with example #7, “Image Gallery Study”, but the whole site is worth exploring. Bonus: make sure to responsively test the top of the page, which has some great Grid-driven rearrangements as the page gets more narrow.
- Rachel Andrews’ Grid By Example — a large and growing collection of examples, resources, tutorials, and more. There’s a whole section titled “Learn Grid Layout” that’s further broken up into sections like “UI Patterns” and “Video tutorial”.
- CSS-Tricks’ A Complete Guide to Grid — a boiled-down, pared-down, no-nonsense distillation of Grid properties and values. It might be a bit bewildering if you’re new to Grid, but it’s the kind of resource you’ll probably come back to again and again as you’re getting familiar with Grid.
- CSS Grid Layout specification — if all else fails, you can always go to the source, Luke.
But remember! If you hit these sites before March 2017, you’ll need to make sure you have Grid support enabled in your browser so that you can make sense of the examples (not to mention anything you might create yourself). Igalia has a brief and handy how-to page at Enable CSS Grid Layout, and Rachel also has a Browsers page with more information.
I’ve been hurt by layout promises before, and I’m afraid to trust.
I feel you. Oh, do I feel you. But this really looks like the real thing. It’s coming. Get ready.
Great points on why we should be moving forward with CSS grid now. I’ve been learning it lately and can’t wait to start using it in more of my projects. You mentioned that subgrid won’t be ready right away. Maybe that explains why I haven’t been able to get it work, even with flags enabled. Do you know anything more about that?
Super exciting. I have been playing with grid quite a bit lately. Here’e a gallery if anyone wants to use this as a resource as well: http://codepen.io/collection/XRRJGq/
I can’t wait until March (ish)!!!!
So grid will work in 2 browsers in march and we’re supposed to adopt it? Sounds very similar flexbox which is just now getting adopted after several years of waiting for browser support. There’s not enough money is most web projects for me to develop two sets of layout rules. Like you said early on, two to three years, but definitely not in march.
@Pat, the problem with flexbox is that it has different/broken implementations across many browsers and so testing for it is problematic (no support for @supports, false positives, etc). With grid, we’ll be using @supports which should be enough to isolate only those browsers that are capable.
@donny – right but… no Safari support, partial (as of now) support in Edge and IE11 and what’s the support in Android and Mobile Safari?
Yes, Grid looks awesome. Yes, I want to use it. But telling me to code my design twice because 2 popular browsers will have it in March? Uh, I can wait until support’s a bit more widespread. The world will be fine if my first designs with Grid don’t roll out until next September.
There seems to be a small misunderstanding here: I said you can use Grid in March 2017. It won’t have the same problems flexbox had, where there were a couple of years of buggy, incomplete, incompatible, backtracking implementations behind prefixes (and then not behind prefixes).
Whether that’s enough for you personally to use it, well, each person has to make that decision for themselves. I hear a lot of echoes from the time when table layout was adopted, and then again from the time when it was phased out for CSS layout. Thankfully, this transition will be a lot simpler and less chaotic than either of those.
> It won’t have the same problems flexbox had, where there were a couple of years of buggy, incomplete, incompatible, backtracking implementations…
The reasoning for this is because it is behind a flag and supposedly all the bugs will be ironed out before shipping.
You have a lot of faith in: browser vendors; the handful of developers who are beta testing it (because it’s behind a flag); and people’s ability/willingness to upgrade browsers (even with a few evergreen browsers).
My prediction: One browser will release it. Then the rest — not wanting to be critiqued for being late to the party — will launch it with bugs. After several months most evergreen browsers will iron out most of the bugs and it’ll be usable to developers serving modern browsers.
I suspect you’re trying to do a “good” thing and hype it up so people get bug reports in before launch, but inevitably the only people who will jump on it are the layout newbs who won’t think of the fringe cases anyway.
They will, however, figure out a way to write spaghetti code with it. And it won’t work for at least several percent of US customers (probably much more globally).
The person who has to fix it will comb through each line — inevitably re-writing the entire layout from scratch (or desperately wanting to) — cursing the people who promoted this as a “usable”.
I *am* excited about Grid Spec, and I’m pretty biased because I made a similar tool, but my 10+ hour/day, 6-day/week job consists of cleaning up flexbox messes/bugs in browsers less than a year old, so I’m directly concerned that I’ll go from being the flexbox cleaner to the Grid Spec cleaner.
I’d like to make some cool stuff with React, or even just see a cloud before I die.
This won’t be any different from XYZ feature that browsers have known about for years but haven’t fully implemented correctly. For example, here is a list of Grid Spec’s inventor’s backlog: https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/filters/top
You’re right. Grid Spec will be *usable* in early 2017… on our blogs (unless we want potential employers to see them).
Hope I’m wrong. It really is a nice tool.
Im looking forward to learning more about CSS Grid and being ready and up to play when it gets released in March.
PS Thanks for the enjoyable writing style.
Eric, thanks for answering some of the Grid questions. I am very excited for the possibilities that Grid brings to the table. Flexbox has already made so many things easier. I expect Grid to do the same.
I’ve started a blog that I hope will help people learn Grid. There some of my own experiments on there but mostly resources, links, and articles from the people who have been behind Grid’s implementation (Jen Simmons, Rachel Andrew, etc.). You can find it at learncssgrid.wordpress.com. I also have a collection of pens on codepen that show some real-world examples of Grid and what is possible: http://codepen.io/collection/noLOaw/.
Not trying to self-promote, but we need to get a lot of developers working on Grid as quickly as possible to work through bugs but also to unleash the awesome things Grid will bring with it. I’d love to see any work you have done with Grid.
Btw, I just want to thank you for “Eric Meyer on CSS.” It was my first introduction to CSS. I still own it today, along with Zeldman’s web standards book. I appreciate the work you’ve done over the years to help designers, developers, and webmasters. I hope Grid will be a huge leap forward for the design of websites.
I get that people are apprehensive about the level of usability of Grid once it’s released in browsers. But as someone who has been watching Grid (spec and implementation) from the sidelines for the last couple of years, I truly believe that this feature will be a much smoother rollout than any previous layout technology in CSS.
> My prediction: One browser will release it. Then the rest — not wanting to be critiqued for being late to the party — will launch it with bugs. After several months most evergreen browsers will iron out most of the bugs and it’ll be usable to developers serving modern browsers.
As Eric already pointed out, both Firefox and Chrome/Blink have it on their release trains, so the above scenario is probably a bit pessimistic.
Another difference from e.g. flexbox is that the implementation has happened very openly between browser vendors, in terms of ironing out implementation differences.
As for Safari: Igalia, the company who has been doing the Blink implementation, is also implementing it in parallell in WebKit, so with a little luck it should make its way into Safari before long.
Partial implementation in IE10-11/Edge, full (and interoperable) implementations in Firefox, Chrome/Opera/other Chromium/Blink-based browsers plus (soon) Safari, and not a massive need for it in mobile browsers sounds like a pretty sweet deal to me, so I’m optimistic.
It’s not going to be bug free, but very few things are and we can still use them.
My career has consisted of ironing out layout bugs so, yeah, I am pessimistic (I’m a pessimistic person anyway tbh).
I sincerely hope I’m wrong. I hope you’re right about the browsers being in an open/honest process and implementing it in a very standard/bug-free way.
At this point I’m just going to wait for a few months after release to see if a gridbugs repo pops up somewhere with lots of content.
I really would be interested in seeing a thorough estimate of how many users will be left in the cold (assuming we don’t want to do a @supports layout on top of a Grid Spec layout). It’s hard to predict how many people will use various browsers/versions in a few months, but I think some sort of research on this would add to the conversation.
Pixels of the Week – December 9, 2016 - Stéphanie Walter, Web and UX Designer, Mobile enthusiast Blog of Stéphanie Walter, Graphic and Web Designer, designing for User Experience on mobile websites
[…] CSS grid is coming in March 2017!! And any browsers that understand Grid will also understand @supports() […]
La semaine en pixels – 9 décembre 2016 - Stéphanie Walter : design et mobile, UX et UI Stéphanie Walter : design et mobile, UX et UI
[…] CSS grid is coming in March 2017!! CSS grid arrive en mars non préfix dans les navigateurs et tout navigateur qui comprends grid comprendra @supports() donc plus d’excuse pour ne pas l’utiliser […]
Does that mean Flexbox will be obsolete in a couple of years or should we still learn to use it?
Grid is meant to be used hand in hand with Flexbox. Flexbox controls layout in one dimension (x or y) while Grid controls the layout on both the x and y at the same time. So you have the superstructure of the Grid Layout and inside your grid structure you can use Flexbox to control the layout on a single axis (horizontal or vertical).
Does that make sense?
Brian’s got it, Kelvin—learning both is absolutely a great idea, as they work in concert, not in opposition. Flexbox may become obsolete in the future, but if so, it’s unlikely it’ll be Grid that causes that. It’ll more likely come from flexbox changing in major ways, or being scrapped in favor of something more powerful with the same aim: to manage one-axis layout.
I’d add that Grid Layout utilizes flexbox’s API for things applied to grid elements (that is, their parent isn’t explicitly set to `display: flex`).
I believe `order` works as well (which is actually reeeally nice).
I think flexbox will still be useful in certain contexts, but Grid Layout adopting flexbox’s API was a stroke of genius.
There will be plenty of non-grid situations in web design where it will be good and appropriate to have/use Flexbox. Having worked with Grid over the past couple of months I can see that it doesn’t fit all projects well. It’s really great for the ones it does fit, though. So I don’t see Flexbox going away anytime soon.
I’m a CSS newbie and just started to learn about flexbox yesterday. Then I found grid. I immediately wondered why people still use float instead of grid. Turns out it’s not released yet haha
I enjoy reading your article and the comments. I also had doubts about starting to use flexbox because I thought it will soon be outdated but I learned from the comments that flexbox can be used together with grid.
Bruce Lawson’s personal site : Reading List
[…] CSS Grid! – FAQ and some links by glamorous Eric Meyer […]
Discoveries of the Month – December/2016 – Vinícius Rezende
[…] CSS Grid: CSS Grid is going to become supported-by-default in Chrome and Firefox in March of 2017. Checkout more information on the link. […]
CSS Grids Made Easy: The Ultimate Tutorial ⋆ telepathics
[…] some neat notes […]
> I’m guessing that you do have a layout that functions in older browsers, yes?
Well, we’re currently starting to work on a brand new project, with a brand new layout/design. So, no we haven’t.
Do you recommend we develop two layouts? Grid first, or flex first?
Hey, David! I recommend prototyping with grid, because it will be super-fast to rearrange things and also will get you familiar with grid. For production, keep the grid and write flex for the browsers that don’t understand grid. You can use
@supportsto hide away the grid stuff if need be, though you might not need to. And who knows, by the time you deploy the new design, you might be able to skip the flex fallback altogether, thanks to evergreen browser updates.
How does grid affect page load time?
I haven’t seen too many page load time differences, but I haven’t done extensive console profiling. In experiments, I have found that particularly long pages that have both explicit grid placement and auto-flow grid placement can cause some layout hiccups, but not universally, and I haven’t narrowed down a testcase yet. Here on meyerweb, I haven’t noticed any difference at all in load times, even though pages like the home page are pretty long.
I’ve made a Chrome extension to perform CSS grid inspection.
looking for some feedback and corner cases