Responsive design?

Let’s first take a minute to talk about 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). Instead of serving a desktop site and a separate, minimal mobile version (if at all)—you could instead adapt one site.

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 subsequent proliferation of its paradigm in Android—the web, and then word, scrambled to respond.

Decent illustration from Wikipedia.

`meta name="viewport"`

You might have noticed this line in the head of our HTML templates:

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

When the iPhone came on the scene, sites didn’t have narrow/smaller (responsive) layouts so the phone would instead scale or zoom out a desktop site design to fit. Websites then were often designed to a standard 960px width, which the phone shrank down to its 320px screen—and then the user could zoom in or out. It worked, but it was less than ideal.

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

The width=device-width tells the browser to use whatever the screen’s actual pixel dimension is, and initial-scale=1 sets the starting zoom of 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.

From the iPhone introduction, worth a watch. He definitely “dented the universe.”

Simpler times.

Media queries

Responsive design could only really flourish when CSS added the @media at-rule around the same time. These are colloquially called media queries, and they allow us to check if screen is a certain width or resolution (or other features, which we’ll get to)—and then apply selective CSS only in that scenario.

Practically, these are blocks of CSS—a little bit like *selectors* that contain other selectors—but which only apply conditionally when the test/criteria is met.

/* Our CSS has all been out here. */

**@media some-criteria-or-rule {**
  /* CSS that only applies if the test passes. */
**}**

These blocks are like any other CSS—if there are multiple conditions that are met, the rules cascade down and the lowest one takes precedent.

Width-based breakpoints

There are lots of media queries we can use, but we’ll start with width—which is by far the most commonly used and really the core of responsive design. Usually when folks are talking about a page or site being responsive, they mean with regards to width.

Width will vary the most between devices—from the (now) 375px–428px of your phones, through the ~1440px–1680px of your laptops, up to the ~2560px–3440px you might see on desktop displays. Since this width is usually our primary design constraint (height being handled with scrolling), we need width-based media queries to adjust our layouts across this wide range, lest our designs implode.

*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. This might be 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.

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