You know, we use ad-blockers as well. We gotta keep those servers running though.
Did you know that we publish useful books and run
friendly conferences — crafted for pros like
yourself? E.g. our upcoming SmashingConf Barcelona,
dedicated to smart front-end techniques and design patterns.

Earlier this year, support for CSS grid layout1 landed in most major desktop browsers. Naturally, the specification is one of the hot topics at meet-ups and conferences. After having some conversations about grid and progressive enhancement, I believe that there’s a good amount of uncertainty about using it. I heard some quite interesting questions and statements, which I want to address in this post.

“Too bad that it’ll take some more years before we can use grid in production.”

“Do I need Modernizr in order to make websites with CSS grid layout?”

“If I wanted to use grid today, I’d have to build two to three versions of my website.”

“Progressive enhancement sounds great in theory, but I don’t think it’s possible to implement in real projects.”

“How much does progressive enhancement cost?”

These are all good questions, and not all of them are easy to answer, but I’m happy to share my approach. The CSS grid layout module is one of the most exciting developments since responsive design. We should try to get the best out of it as soon as possible, if it makes sense for us and our projects.

Before going into detail and expounding my thoughts on the questions and statements above, I want to present a little demo42 I’ve made.

Disclaimer: It would be best to open the demo on a device with a large screen. You won’t see anything of significance on a smartphone.

3The home page of an example website, with an adjustable slider to switch between different layout techniques.

When you open the demo42, you’ll find yourself on the home page of a website with a very basic layout. You can adjust the slider in the top left to enhance the experience. The layout switches from being very basic to being a float-based layout to being a flexbox layout and, finally, to being one that uses grid.

It’s not the most beautiful or complex design, but it’s good enough to demonstrate which shapes a website can take based on a browser’s capabilities.

This demo page is built with CSS grid layout and doesn’t use any prefixed properties or polyfills. It’s accessible and usable for users in Internet Explorer (IE) 8, Opera Mini in Extreme mode, UC Browser and, of course, the most popular modern browsers. You can perfectly use CSS grid layout today if you don’t expect exactly the same appearance in every single browser, which isn’t possible to achieve nowadays anyway. I’m well aware that this decision isn’t always up to us developers, but I believe that our clients are willing to accept those differences if they understand the benefits (future-proof design, better accessibility and better performance). On top of that, I believe that our clients and users have — thanks to responsive design — already learned that websites don’t look the same in every device and browser.

In the following sections, I’m going to show you how I built parts of the demo and why some things just work out of the box.

Quick side note: I had to add a few lines of JavaScript and CSS (an HTML5 shim) in order to make the page work in IE 8. I couldn’t resist, because IE 8+ just sounds more impressive than IE 9+.

I started off by putting all items into a section in a logical order. The first item in the section is the heading, followed by four subsections. Assuming that they represent separate blog posts, I wrapped each of them in an article tag. Each article consists of a heading (h3) and a linked image. I used the picture element here because I want to serve users with a different image if the viewport is wide enough. Here, we already have the first example of good ol’ progressive enhancement in action. If the browser doesn’t understand picture and source, it will still show the img, which is also a child of the picture element.

On larger screens, this component works best if all items are laid out next to each other. In order to achieve that for browsers that don’t understand flexbox or grid, I float them, give them a size and some margin, and clear the floating after the last floated item.

In this example, I actually don’t need to enhance the general layout of the component with flexbox, because floating already does what I need. In the design, the headings are below the images, which is something that’s achievable with flexbox.

article {
display: flex;
flex-direction: column;
}
h3 {
order: 1;
}

We have to be very cautious when reordering items with flexbox. We should use it only for visual changes, and make sure that reordering doesn’t change the user experience for keyboard or screen-reader users for the worse.

Everything looks pretty good now, but the heading still needs some positioning. There are many ways to position the heading right above the second item. The easiest and most flexible way I found is to use CSS grid layout.

First, I drew a four-column grid, with a 20-pixel gutter on the parent container.

If I extract the extra lines that I need to make this thing work in IE 9+, then we’ll get a total of eight lines (three of which are actually for the clearfix and are reusable). Compare that to the overhead you get when you use prefixes.

I know that that’s just a simple example and not a complete project, and I know that a website has way more complex components. However, imagine how much more time it would take to build a layout that would look pixel-perfectly the same across all the various browsers.

In the preceding example, width was the only property that had to be reset. One of the great things about grid (and flexbox, too, by the way) is that certain properties lose their power if they’re applied to a flex or grid item. float, for example, has no effect if the element it’s applied to is within a grid container. That’s the same for some other properties:

If you do have to overwrite properties, use feature queries11. In most cases, you’ll only need them to overwrite properties such as width or margin. Support for feature queries12 is really good, and the best part is that they’re supported by every browser that understands grid as well. You don’t need Modernizr13 for that.

The only time when it got a little tricky for me while working on the demo was when there was a flex or grid container with a clearfix applied to it. Pseudo-elements with content become flex or grid items as well15. It may or may not affect you; just be aware of it. As an alternative, you can clear the parent with overflow: hidden, if that works for you.

Browsers already do a lot of progressive enhancement for us. I already mentioned the picture element, which falls back to the img element. Another example is the email input field, which falls back to a simple text input field if the browser doesn’t understand it. Another example is the range slider that I’m using in the demo. In most browsers, it’s rendered as an adjustable slider. The input type range isn’t supported in IE 9, for example, but it’s still usable because it falls back to a simple input field. The user has to enter the correct values manually, which isn’t as convenient, but it works.

While preparing the demo, I came to the realization that it’s incredibly helpful to really understand CSS, instead of just throwing properties at the browser and hoping for the best. The better you understand how floating, flexbox and grid work and the more you know about browsers, the easier it’ll be for you to progressively enhance.

Becoming someone who understands CSS, rather than someone who just uses CSS, will give you a huge advantage in your work.

Also, if progressive enhancement is already deeply integrated into your process of making websites, then it would be difficult to say how much extra it costs, because, well, that’s just how you make websites. Aaron Gustafson shares a few stories of some projects he has worked on in his post “The True Cost of Progressive Enhancement17” and on the Relative Paths podcast18. I highly recommend that you listen to and read about his experiences.

Progressive enhancement might involve some work in the beginning, but it can save you time and money in the long run. We don’t know which devices, operating systems or browsers our users will be using next to access our websites. If we provide an accessible and usable experience for less capable browsers, then we’re building products that are resilient and better prepared for new and unexpected developments20.

I have the feeling that some of us forget what our job is all about and maybe even forget that what we’re actually doing is “just” a job. We’re not rock stars, ninjas, artisans or gurus, and what we do is ultimately about putting content online for people to consume as easily as possible.

That sounds boring, I know, but it doesn’t have to be. We can use the hottest cutting-edge technologies and fancy techniques, as long as we don’t forget who we are making websites for: users. Our users aren’t all the same, nor do they use the same device, OS, browser, Internet provider or input device. By providing a basic experience to begin with, we can get the best out of the modern web without compromising accessibility.

Grid, for example, is available in almost every major browser26, and we shouldn’t wait more years still until coverage is 100% in order to use it in production, because it’ll never be there. That’s just not how the web works.

Manuel Matuzović is a frontend developer from Vienna, who's passionate about accessibility, progressive enhancement, performance, and web standards. He's one of the organizers of a meetup called webclerks. You can follow him on Twitter or read more of his articles on Medium.

Jason

This is where css variables come into play. They are like SASS/LESS, except they are rendered in real time and don’t have to be compiled. Just set your default value in a var, use that var everywhere, then JS can adjust that var however you wish.

Marina

basher

1. You say you’re not using Modernizr, but you are “spoofing” Modernizr by adding classes to your HTML element (with your slider) which you’re then utilizing in your CSS selectors.

2. How would you deal with legacy Grid and Flexbox syntax?

I’ve been working on a demo (mobile first, progressive enhancement, etc) and have come up with a slightly different approach that uses Modernizr to detect Flexbox, but uses @supports directive to differentiate latest and old Grid syntax (particularly for MS Edge):

Manuel Matuzović

1. I’m not “spoofing” Modernizr. The classes are added by adjusting the slider not by checking features. They are only there to demonstrate the various stages of enhancement. Maybe you missed it, but I made another Pen for one of the components without the slider..

2. I’d deal with it the way I explained it in the article. Float and standard Flexbox for legacy browsers and Grid for all browsers that support it. If you do it this way you probably don’t have to use prefixed properties at all and any feature detection other than @supports() {}. Have a look at the screenshots at the end of the article. There you can see how the demo looks like in IE8-IE11.

Neha sharma

Adrian Roselli

If you are testing in Edge, then you may already know that @supports (display: grid) will not work (as Edge’s support pre-dates the current syntax used in Grid). To account for Edge, use @supports (grid-area: auto) instead. Obviously, if the syntax you are using within the MQ is not supported by Edge (as in the examples in this article) then the fall-backs prove to be ace.

Manuel Matuzović

Since Edge currently only supports the old spec and I’m not using any prefixes in the demo, Edge users will only see float and Flexbox enhancements. If you want to account for Edge (and IE and future versions of Edge), you’d have to use @supports (display: -ms-grid) {...}.
I didn’t mention Edge explicitly because for me it’s one of the „modern browsers.“ despite the lack of support for the new spec.
As far as I’m concerned @supports (display: grid) {...} and @supports (grid-area: auto) {...} do the same thing. There was a bug in an Insiders build of Edge 15 where checking for a property that doesn’t exist in the old spec was necessary, but it never made it into a stable release. You can use this pen to check @supports() and Grid in various browsers.

Adrian Roselli

@Manuel Matuzović, per our Twitter conversation (https://twitter.com/aardrian/status/890049083351732224), I misunderstood the post to suggest that Edge supported the Grid used in the article. It was not clear to me that was not the case. Either way, I prefer to avoid prefixed MQs, which is why I explored the grid-area: auto approach.

Since Edge evaluates @supports (display: grid) to true, I assumed the non-Grid layout was a function of a bad MQ. It turns out (as you can see in the Twitter thread) that Edge was only supposed to get the Flex layout. That was not clear to me when I read the article.

Konstantin

Thank you for this inspiring article. I really like the idea of Progressive Enhancement.
Little note from me, As for I understand in part of the Grid Enhancements in your code snippet for the second article you don’t need this part of the code:

Subscribe to our email newsletter for useful tips and valuable resources, sent out every second Tuesday.

Please provide us with your email address:

As designing static pages has become untenable, many have started to approach design in a modular way.
In this book, we’ll identify what makes an effective design system that empowers teams to
create great digital products.
Pre-order the book now →

Today, too many websites are still inaccessible. In our new book
Inclusive Design Patterns, we explore how to craft
flexible front-end design patterns and make future-proof and accessible interfaces without extra effort. Hardcover, 312 pages.
Get the book →

Meet the new Sketch Handbook, our brand
new Smashing book that will help you master all the tricky, advanced facets of Sketch. Filled with
practical examples and tutorials in 12 chapters, the book will help you become more proficient in your work.
Get the book.

Trends don’t matter, but techniques do.
With SmashingConf Barcelona, we’ll explore problems,
smart solutions and lessons learned from actual projects.
Taking place on October 17–18 at the Palau de la Música Catalana.
To the tickets →

Home sweet home! On September 11–12th, we're gathering for our 6thSmashingConf Freiburg right next to the legendary Black Forest.
With Umar Hansa, Rachel Andrew, Alla Kholmatova, Chris Wright, and others.
To the tickets →