Should we still be selling responsive web design?

Working in a UX design agency, the term ‘responsive web design’ seems to have been a mainstay in the world of digital development for many years – this blog has posts on the topic going all the way back to 2014, for example. Even so, go to any early-stage client meeting and you’ll still almost always get asked to ‘make sure it works on mobile’.

The standard reply to this has generally been, ‘don’t worry, we’ll build it responsive’, but I think this statement is becoming more and more out of date. Here’s why.

The limitations of responsive web design

The main ‘tool’ of responsive web design is the ‘media-query’. This lets us apply a subset of CSS only when a website or web app is rendered at a specific size, orientation or when some chosen environmental criterion is met (for example, light level). This allows a front-end developer to easily manipulate how a website, digital product or app displays on different-sized devices, or as a window size changes.

However, I’m starting to think that tying rules about how an element should display to the size of the overall page or device is very short-sighted. This is especially true in today’s world of component-driven design.

Component-driven design changes everything

Today, in modern web design, we usually build highly reusable, environment agnostic components using methodologies such as Atomic Design, often with the aim of building out a pattern library to be used across a variety of applications. This approach saves time and money, as it reduces the need to duplicate work. There is a burden, however, as each individual component needs to be robust enough that they work appropriately when dropped into containers of different sizes.

For example, if we built a news item preview component, with an image above a text excerpt, this may display in a wide container (e.g. an index page), or within a sidebar (e.g. related articles). If we write a media query that changes the news item’s display based on the size of the viewport (for instance placing the image alongside the copy instead of above it) we will be limiting the contexts when this item is useful. This is because if the viewport is wide, the rule will apply, even if the component is being used in the sidebar where it doesn’t have adequate space.

This is the crux of my complaint; media queries are very manual and explicit. Instead of defining the ideal state for a component, we are forced to place it in context and test how it works in relation to the canvas, and then manually adjust. If you’re anything like me, you’ll find yourself doing the adjustment optically and then explicitly writing rules to tweak the display to your liking. If the page layout changes – and therefore how the module sits on the page – you will likely have to reassess these rules. This creates a huge maintainability burden and makes it easy for components to visually ‘break’ at certain viewport sizes, unbeknownst to the person making the changes.

Responsive web design, up to this point, has been concerned with the canvas, but what is really needed is a component-driven mindset.

Intrinsic web design

In 2018 Mozilla Designer Advocate Jen Simmons coined the term ‘intrinsic web design‘. This methodology takes a more content-out approach to digital design. Instead of changing styles based on the size of a viewport (or how big the screen of the device is), components automatically lay out based on their own ‘ideal’ conditions.

For instance, instead of saying at 768px wide, the news article image sits above the text instead of alongside it, we could give more rough guidelines: ‘the image should span the full width of the parent, but ideally be no bigger than 250px wide’. Then, when the image hits 250px, it will automatically move to sit alongside the text.

We can describe responsive/adaptive design as an imperative approach – you are describing explicit behaviour to occur at an explicit width. Intrinsic design, meanwhile, has more in common with a declarative approach; we are providing guidelines, but leaving the precise implementation up to the browser.

Flexbox, grid and multi-column layout

Intrinsic design is largely enabled by new(ish) layout methods such as CSS Flexbox and CSS Grid (using auto-layout). These are all complementary technologies and don’t replace one another – Grid is two-dimensional, Flexbox is one-dimensional.

Below is an example of how we might use CSS Flexbox to create an automatically adapting media-query-less component:

ul {
    display: flex;
    flex-wrap: wrap;
}

li {
    flex-grow: 1;
    flex-basis: 250px;
}

This is saying that when list items get smaller than 250px, they should wrap. 250px is their ‘ideal’ size, but they can grow to fill additional space.

Here is a further example with CSS Grid:

ul {
  grid-template-columns: repeat( auto-fit, minmax(250px, 1fr) );
}

This is saying, when columns get smaller than 250px wide, they should occupy their own row. We don’t need to explicitly say when to switch layout, instead, we are providing a content-driven rule. It is not bound to the viewport size, but the width of the content itself so can be used within nested elements. If the grid is used within a small sidebar, for instance, it will be a single column, while if it is also used in a content area next to the sidebar (larger than 250px * 2), then it will split into columns.

Alternatively, we could use a CSS multi-column layout with the column-width property:

ul {
  column-width: 250px;
}

The behaviour of these three examples is all subtly different, with variances around the width of the wrapping items, and the distribution once they wrap. However the premise is the same: we advise the ideal width of an element, and let the browser worry about when and how to wrap.

These examples are ‘contextual’ and more ‘responsive’ than responsive web design, since they respond to their environment, not the viewport.

Bring on container queries

I expect that at some point in the future element or container queries will be introduced, and this post will be rendered moot. Certainly, until that point, it’s hard to fully do away with media queries, as much as I’d like to.

In the meantime, it is possible to point to the clever work that’s been done to make components responsive to their parent, not the page width. However, to me, a lot of these solutions are restrictively contextual.

So, where does that leave us?

Well, no, responsive web design isn’t dead, but we are at the point where we’ve evolved past what most people mean when they use the term. We’re no longer just trying to fit the things we make to varying screen sizes.

Instead, we’re now building digital products in a more flexible, module-driven way, and we have better tools now than five years ago that make working like this easy. We’re designing at the modular level, rather than the screen size level, and we’re moving to a more declarative approach.

It’s still OK to call this responsive web design – the term still makes sense – but I think we should be doing a better job of educating our customers about the new types of stimulus we’re responding to as designers. If we don’t, how will we ever move the conversation on from ‘make sure it works on mobile’?