Can you progressively enhance a layout?

Oliver Williams
Nov 15, 2016 · 3 min read

I’ve experimented a lot with grid without thinking about progressive enhancement. I was making Codepen’s for no other purpose other than learning the spec. Almost all of them break into an embarrassing mess in non-supportive browsers.

Here’s how a recent experiment looks in Firefox Nightly
Here’s how it looks in Safari. Not my finest work…

Grid looks set to be unleashed on all browsers at the beginning of next year. As the prospect of building an actual commercial site for a client approaches, I’ve started to think about how to deal with older browsers. I started reading Aaron Gustafson’s book Adaptive Web Design: Crafting Rich Experiences with Progressive Enhancement. While not mentioning CSS grid, it certainly re-emphasized the importance of the concept in my mind.

Crafting Rich Experiences with Progressive Enhancement

For a recent CodePen experiment it was as simple as turning the grid into a flex-container and giving the grid-items (now flex-items) some margins and and a height & width:

@supports not(display: grid) {
.item {
height: 100px;
width: 100px;
margin: 20px;
.grid {
display: flex;
flex-wrap: wrap;

What if you want to support browsers that don’t even support @supports? Simply use the cascading nature of CSS. If it’s old enough to have not implemented @supports it is unlikely to support flexbox, but we could give a basic float layout at the top of our stylesheet, and then overwrite it further down with

@supports (display: grid) { 
styles to overwrite float layout

The philosophy of progressive enhancement is about building in layers. You could start by thinking: what can I easily achieve with traditional layout methods? Then ask what can I easily enhance with flexbox? And then go crazy with grid layout. But again, if floats were anything other than a hack and perpetual annoyance, we wouldn’t need grid. Potentially, you could make use of @supports to deliver both a grid-layout and a complex float-based layout, but why would you? When I tried to retrospectively cater to older browsers, I found myself writing @supports nested inside a media query, and vice versa — a recipe for a labyrinthine mess of complicated code. I found myself agreeing with Matt Hinchliffe, a developer at the Financial Times.

Rather than thinking mobile-first, we should think both mobile & non-grid-browser first. Being a stacked-block single columns is the default sans-grid, and often doesn’t look so bad. Perhaps this is something of a catch-22: if mobile style layouts looked amazing on desktop, we would have no need for grid systems. But this is why we call it an enhancement. Our content needs to be readable and accessible for older browsers — it need not look perfect, just functional. The whole reason we adopt a new tool is so that it makes our life easier, not so that we make our lives harder by having to deliver a layout in multiple ways.

Rachel Andrew and Jen Simmons have a interesting discussion about this issue on the indispensable podcast The Web Ahead. I’ll probably come back to this topic at some point.

Oliver Williams

Written by

Frontend developer at Suntory. Ex Springer Nature



thoughts on cascading style sheets + front end

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade