Responsive Design

This term was coined in 2010 or so by Ethan Marcotte⁠—wrapping a name around a progressive enhancement and mobile-first web design approach/​philosophy that had been growing in the mid-2000s (sometimes called liquid, flexible, fluid, or elastic design).

• Responsive Design – MDN
  A pretty nice overview.

• Beginner’s Guide to Media Queries – MDN
  Slightly overlapping, but also good.

• Using Media Queries – MDN
  Okay, that’s probably enough MDN.

• Using CSS Custom Properties – MDN
  Sorry, last one! For now.

Instead of building, designing, and serving a desktop site and a separate, minimal mobile version (if you even did at all)⁠—you could instead adapt one site to work across devices. This is responsive design.

There was a confluence of events that allowed this: modern, self-updating browsers, and then the explosion of the mobile web⁠—precipitated, in no small part, by the iPhone in 2007. It ran a desktop-class browser (in terms of functionality), which hadn’t been available in a small screen before. And with its crazy success⁠—and the subsequent proliferation of its paradigm in Android⁠—the web, and then world, scrambled to respond.

Empty your mind. Be formless, shapeless, like water.

You put water into a cup, it becomes the cup. You put water into a bottle, it becomes the bottle. You put it into a teapot, it becomes the teapot.

Now water can flow or it can crash. Be water, my friend.

Bruce Lee, 1971

Content is like water.

Content’s going to take many forms, flow into many different containers, many of which we haven’t even imagined yet. Build from content out, not container in.

Josh Clark, 2012

There wasn’t much of a mobile web, prior to the iPhone. Some sites had barebones WAP mobile versions, designed for the tiny screens and limited hardware of the era.

When the iPhone came on the scene, most desktop websites still didn’t have narrow/​smaller (let alone flexible) layouts⁠—so the phone would instead scale or zoom out a desktop site design down to fit.

Websites at the time were often designed to a standard width (usually 960px), which the phone shrank down to its 320px screen⁠—and then the user could zoom in or out, scrolling around to view the whole page. It somewhat worked⁠—and all the content was there, unlike most mobile sites⁠—but it was less than ideal.

Viewport <meta> Tag

You’ll see this meta element in the head of most websites, now:

						<meta name="viewport" content="width=device-width, initial-scale=1">

			
	

This meta element tells the browser not to do this scaling. It says, “I have a responsive design! Render me at my actual size. My content can reflow.”

The width=device-width tells the browser to use whatever the screen’s actual pixel dimension is, and the initial-scale=1 sets the starting zoom for the page to 100%. This is how the browser knows how to make the page respond, and how our CSS rules know what width to use.

We call the portion of the page visible at one time the viewport.

Since this width is usually our primary design constraint (height being handled through scrolling), we need width-based media queries to adjust our layouts across this wide range, lest our designs fall.

This is done in steps, at different widths, that we call breakpoints⁠—the window/​device/​viewport sizes where the content starts to break, if it is not adjusted.

If you think responsive’s simple, I feel bad for you son. We got 99 viewports, but the iPhone’s just one.

Josh Brewer, 2012

You might add a breakpoint because lines of text get too short or too long, becoming hard to read. It might be to prevent a grid of images from becoming too small on a phone⁠—while you can have many columns on desktop, often you can only have one (or two) on mobile.

You can add as many breakpoints as you need to make your page/​design work across devices. Don’t think of these as written for specific devices; write for your design and for your content!

There are very, very few layouts that won’t need some amount of horizontal responsiveness/​breakpoints!

In this example, we would refer to 35rem 550px as our breakpoint:

This width rule/​test/​criteria uses math comparison operators⁠—meaning you can use < > = <= >= :

In a broader code and programming context, it can be helpful to think of media queries as conditional if statements.

We’ll talk about this in detail later with JavaScript, where conditionals are ubiquitous and powerful. You may have also heard of If This Then That, which takes its name from this kind of logic.

You can also be less specific about your width/​height and instead use orientation⁠—like when you rotate your phone. The queries use the wonderfully tenacious names/​values of portrait or landscape:

And speaking of conditional statements⁠—you can also merge multiple media queries into one test/​check, using and. This is often used for a range (to apply something between two breakpoints) or to combine width and height checks, together:

You can also use comma-separated queries (similar to selector lists) to apply or logic⁠—setting the same styles for different scenarios:

There is also a not logic operator⁠—which will reverse the meaning of the media query. But this syntax gets confusing fast⁠—especially with things like >/​< rules making for double-negatives. So it is easier to avoid!

Why say not portrait when you can just say landscape?

So this can all get very complicated, very quickly⁠—especially with complex designs, overlapping rules, and the wide ranges of devices to consider.

• Mobile First – A Book Apart
  Luke Wroblewski wrote the book (and the deck).

• Progressive Enhancement – Wikipedia
  The term coined by Steve Champeon and Nick Finck in 2003.

One of the easiest methodologies to keep things understandable is practicing mobile-first design (and development). This has become kind of buzzwordy in the past decade or so, but it is a good philosophy to adhere to, nonetheless. It jives with the concept of progressive enhancement.

Your design constraints will be tighter and more challenging, by tackling your smallest layout first⁠—but it is almost always easier to scale things up than scale them down. A mobile design can always work as a passable desktop one; the reverse is rarely true. Another way to think of it:

If it doesn’t work on mobile, it doesn’t work.

• In Design:

  Mobile-first means considering small screens and then adding complexity, limits, or considerations for larger screens. Start from your “worst-case scenario.”

• In Code:

  Similarly, this means writing your styles for mobile… first, then adding width > # breakpoints (cascading below them) to progressively enhance your design as it scales up.

This goes “with the grain,” following the general CSS pattern/​paradigm of the cascade⁠—and is much, much, much easier than adjusting desktop front-end after the fact. (Trust us.) Always think mobile-first !

Mobile can be the majority of your traffic⁠—especially internationally! We’d like you to think of mobile-first design as a form of accessibility, in this light. Not everyone has your MacBook Pro.

Custom properties (folks almost always say CSS variables) aren’t strictly a part of responsive design or media queries, per se⁠—but they come up very often in modern, mobile-first practice and we’ll introduce them briefly, here. They allow you codify the relationships in your design.

CSS Custom Properties Guide – CSS Tricks
Web guru Chris Coyier’s robust overview.

						:root {
	--brand-color: #e42a1d; /* Declare it. */
}

.brand-color {
	color: var(--brand-color); /* Reference it. */
}

			
	

You can use these as values for any CSS property⁠—colors, spacing, etc.⁠—anything you use multiple times and want to be consistent, give a memorable name to, or easily change all together:

You’ll often declare a set of variables for mobile⁠—type sizes, spacing, and so on⁠—and then adjust them, once, for desktop. No need to write all the properties out again, with all their own redundant media-queries! Variables are great. It used to be so much harder.

They’ll help you avoid unwanted cascade (applying the same property), especially across breakpoints. But they also help to facilitate design system thinking⁠—focusing your design on the relative relationships of things.

Variables are how you build design systems. Like relative type scaling, they help to identify, catalyze, and maintain relationships in your work.

By far, the most common media queries will be width/​height/​orientation⁠—for adjusting your layouts across devices. But @media has some more tricks up its sleeve in testing for other browser features. We’ll look at some of the handy/​common ones.

@media types/​features - MDN
There are many of these! Meet your users where they are.

prefers-contrast /​ prefers-reduced-motion

These last two are primarily concerned with accessiblity⁠—prefers-contrast for folks who run their device/​browser in a high-contrast mode to help with their vision, or prefers-reduced-motion for those who have animations turned off for vestibular reasons.

• prefers-contrast - MDN
• prefers-reduced-motion - MDN
  You can think of both subtlety and motion as progressive enhancements.

Or these are just their preference! None of your business.

						:root {
	/* Default to high contrast… */
	--background: white;
	--foreground: black;
}

p {
	background-color: var(--background);
	color: var(--foreground);
}

/* When “Increase Contrast” is *not* enabled. */
@media (prefers-contrast: no-preference) {
	:root {
		/* …use designer/subtle/nuanced colors. */
		--background: lightgray;
		--foreground: slategray;
	}
}

			
	

						/* When “Reduce Motion” is *not* enabled. */
@media (prefers-reduced-motion: no-preference) {
	button {
		animation: some-slick-animation;
	}
}

			
	

The power of the Web is in its universality.

Access by everyone regardless of disability is an essential aspect.

Tim Berners-Lee, 1997