Illustration of browser window folded like a map with grid lines
As someone who’s been thinking about responsive design theory and building fluid CSS grids with media queries for the last six months or so, I began to notice that I was spending a lot of time and effort massaging my media queries to get things to scale nicely.
It became so bothersome during a recent responsive project at Palantir that I began to think that maybe something wasn’t quite right, as I was continually having to finesse the coverage of a query to compensate for a certain layout becoming awkward at a certain width.
As I continued experimenting and researching the subject I came across a series of articles by Stephanie Rieger, Marc Drummond, and Jeffrey Zeldman that alluded to this same issue. They have a nice little exchange of ideas on the role breakpoints and fluid grids in responsive design. It’s kind of a long story, so bear with me.
Android has some things about it that make it hard to design for. First off, since it’s open source, there are different versions of the OS in existence, and modifications are constantly being made to them. Secondly, there are also some features that can prove meddlesome such as Zoom Level and orientation changes that trigger a new resolution to adjust for readability. And lastly, the huge popularity of the OS among device-makers resulting in many different types of browser chrome.
On December 28th, Stephanie Rieger posted about the difficulty of designing for Android phones and the multitude of viewport possibilities they present:
If instead, you have built your mobile site using fixed widths (believing that you’ve designed to suit the most ‘popular’ screen size), or are planning to serve specific sites to specific devices based on detection of screen size, Android’s settings should serve to reconfirm how counterproductive a practice this can be. Designing to fixed screen sizes is in fact never a good idea…there is just too much variation, even amongst ‘popular’ devices. — Rieger, The trouble with Android
This seems like a pretty strong support for fluid grids as it would be a fool’s errand to try to write a separate media query for each single screen size out there, especially considering the proliferation of Android devices and the elements out of the designers control discussed above. However, after reading Rieger’s article, Marc Drummond concluded that:
If you are using responsive web design techniques (and you probably should be!), then this means that using default media query device-width breakpoints is mostly pointless... Use awkwardness as your guideline, not ephemeral default device widths. — Drummond, Responsive web design default breakpoints are dead
To which Zeldman responded:
Of course, if breakpoints are dead, responsive design is dead, because responsive design relies on breakpoints both in creative workflow and as a key to establishing user-need-and-context-based master layouts, i.e. a minimal layout for the user with a tiny screen and not much bandwidth, a more fleshed-out one for the netbook user, and so on. — Zeldman, State of the web: of apps devices, and breakpoints
Drummond then revised his thoughts and posted this update to his article:
...it’s not as if you can’t keep using common device sizes as breakpoints. If you are using a fluid grid and fluid images, there is a decent chance that a layout with a slightly different width will still look ok... It may be that when your design encounters a browser width slightly larger or slightly smaller than the one you envisioned based on common device sizes, your design may... not look quite right. In that case, you might be better off finding a more natural breakpoint... — Drummond, Long live natural responsive web design breakpoints
And now we’ve finally come to it. In my view, Drummond initially jumped to the wrong conclusion but he does have a point nonetheless — there truly are places within fluid-grid layouts where there is an undeniable awkwardness which I have struggled with myself. I think Drummond is on the right track in searching for more natural breakpoints, but how to go about finding them?
Previously, I had come to address each awkward point on an ad hoc basis by adding another media query within a larger one. As it turns out, Rieger had come to the same solution:
The major breakpoints create the broad stroke changes that are required when moving from the small(er) screen (‘mobile’), to a much wider one (often a tablet-like device), to an even wider one (often a desktop but increasingly there can be higher breakpoints for TVs etc). These major breakpoints are set using media queries in the document head. The minor breakpoints live within those 2-4 style sheets and provide (mostly) the tweaks needed to remove awkwardness. — Rieger, On designing content-out (a response to Zeldman and others)
While this method is a solution, I feel it may not be the solution. To me, it seems far too labor-intensive and more of a one-off kind of approach, and therefore not very extensible. I feel there just has to be a more system-wide type of approach to the problem.
Currently, in responsive design the way we structure media queries is to employ a given query until its layout starts to break down visually, and then we create a new one and put it right next to the first one, repeating the process until the desired spectrum of device widths are covered. Then breakpoints are inserted at canonical viewport widths of 320, 768, 1024 and so on to create your mobile tablet and desktop layouts. (see below)
But in my opinion, that doesn’t really seem like a great idea because what one sees at any given breakpoint is a layout in its most stressed state, i.e. the extreme edges of the query where a layout is being stretched to its limit. Instead, I think it might make more sense to shift the media queries down a bit so that the “sweet-spot” sits right in the middle of the device defining viewport. (see below)
Repositioning the “sweet-spot” over the canonical viewports means that the same layout can now be applied to a range of viewports on both sides of these device widths that have come to define our device-types of smartphone, tablet, and so on. In this scenario, the flexible width layout can now work harder for us. The awkwardness is still there, yes, but its effect on the viewer has been lessened by being moved away from our device-type viewports. This seems like a great method for finding those “more natural breakpoints” Drummond was looking for while still being sort of a device-driven solution.
Not only will incorporating this idea with today’s accepted best practices reduce the amount of “awkwardness adjustment” needed, but it will help you avoid having to create more numerous, smaller sized media queries — which reduces the elegance of the solution and bloats the code. With this shift in thinking, I think you can deliver a more adaptable grid while improving the browsing experience for the majority of your site’s viewers. Sounds like a win to me.