Over the last few weeks many more web developers and designers have become engaged in the conversation surrounding responsive images. On the whole, this is great news because the more people we have telling browser makers that this is a legitimate issue, the more likely it is to get addressed quickly.
However, some of the conversations about responsive images end up going in circles because people are talking past each other. I believe this is happening because we don’t have a common framework to look at the problem.
I believe there are two separate, but related issues that need to be solved regarding the use of the img element in responsive designs. They are:
1. How do we enable authors so that they can display different images under different conditions based on art direction?
When the image is displayed at larger sizes, it makes sense for the image to show the automobile factory in the background. The background helps explain where the event took place and adds to the image. But look what happens when we scale the image down to fit a smaller screen.
At that size, you can barely recognize Obama. You can’t make out his face. Instead of simply resizing the image, it may make sense to crop the image to get rid of some of the background and focus in on him. The end result is an image that works better at the smaller size:
This is what I refer to as enabling art direction. Authors need to be able to provide different sources for images at different sizes not based on resolution or based on network speed, but based on the judgment of the designer for what is the best image at a particular breakpoint.
As an aside, showing photographs at different sizes to illustrate a point is more difficult when you’re dealing with flexible images in a responsive design. If those examples don’t make sense on your phone, I’m afraid you may have to look at it on a wider screen to see what I’m talking about! :-)
2. Enabling authors to provide different resolutions of images based on a variety of conditions.
When people talk about how to handle images for retina displays, they are talking about this second issue. The same is true of making decisions about the size of images based on bandwidth. All are dealing with how to deliver different resolutions based on conditions (pixel density, network speed, etc.).
Apple’s proposed addition to CSS4, image-set, is designed to solve this issue in CSS. Authors define images at different densities and the browser picks the best one based on some criteria that could be as simple as pixel density or as complex as a combination of observed network speed, pixel density, and user preference. What the criteria is remains to be defined.
Where the <picture> element fits
The proposed <picture> element attempts to solve issue #1. It focuses on how to give authors the ability to specify different images, but doesn’t do anything about pixel density or bandwidth.
I’ve seen a lot of feedback on the <picture> element that says we should have a new type of image format to replace JPEG, PNG and GIF that would be resolution independent. That would be awesome. And it would solve issue #2, but it wouldn’t help with the art direction outlined in issue #1.
When we discuss various solutions, it behooves us to figure out which issue we’re trying to solve. We can also debate whether or not the two issues I outlined are legitimate or if there are other issues that aren’t addressed by them.
But in order to have a fruitful discussion about how to solve these issues, we need to be clear about which issues we’re talking about or we’ll end up wasting more time. What I often see in comment threads and on Twitter is two people debating different solutions for responsive images, both looking at different issues, and neither realizing that the other isn’t looking at the same problem.
My hope is that by defining these issues, we can stop spinning our wheels and have more successful discussions.
Over the last few months, I’ve been proud to represent Portland as the WebVisions conference branched out into other cities. It’s been awesome to see “the little conference that could” find new communities eager to welcome it.
Despite that fact, I’ll freely admit that I have a special affection for the Portland version of WebVisions. It was the first conference I attend and the first one I spoke at. There are talks that I saw at WebVisions that still influence my work to this day.
This is the 12th year of the conference. The organizers bring in fantastic speakers and do so at a price that is much less expensive than what it costs to attend most other conferences. At my previous job, I would often take our entire team to WebVisions.
This year is no different. The conference starts on May 16th. Lyza and I will be giving a workshop showing desktop web developers how to convert their skills to mobile. I’m also giving a talk called Casting Off Our Desktop Shackles. We’d love to see you at both!
If you’re in the Portland area, I encourage you to attend WebVisions. I love the community around the event. And I like playing host to all of the smart people who travel to our city to attend or speak at WebVisions. If you do attend, please say hello.
It’s been a strange few years for the pixel, that unit we love to hate and generally blithely use anyway.
First, there is the weird brain-bending device pixel versus CSS pixel math we’re all trying to do in our head since we started seeing a lot of high-density digital displays on the market.
Then there’s the whole schizophrenia in the standards worlds about what a pixel even is. Ask the W3C currently, and you’ll get a wholly incomprehensible definition (kind of fun as a drinking game/party laugh) that in the end claims "absolute unit." Ask the Mozilla Developer Network, and you’ll get a brief answer of "relative."1
The reference pixel is the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm’s length. For a nominal arm’s length of 28 inches, the visual angle is therefore about 0.0213 degrees. For reading at arm’s length, 1px thus corresponds to about 0.26 mm (1/96 inch). —Excerpt from the W3C definition of a reference pixel
And this all before we’ve even reached the lively world of viewports: layout viewports, visual viewports, viewport scales. And the different treatment by browsers of zooming—Webkit browsers don’t really scale pixel-based units after a zoom, Mozilla and Opera do. @ppk may understand pixels2, but I think he may be superhuman.
So, pixels may be relative or absolute, big or small, device-specific or theoretical. Here’s the rub at this point: I don’t care.
What’s a pixel? I don’t care
When I wrote the post about The Ems Have it (em-based media queries) a few weeks ago, I was mostly just focusing on the surgical problem of getting Webkit browsers to behave, when you get down to it. I spoke of practicalities: em-based media queries don’t break when you zoom.
But whether or not pixels ultimately do scale in Webkit browsers is beside the (deeper) point. If we’re staying true to a "content first" maxim, it follows, logically, that our media queries—as well as our layouts overall—might benefit by being subordinate to the content itself.
From my perspective, ems are more true to content.
For me, thinking in pixels for media queries ties me into some bad habits. I start thinking as if there is some 320 x 480px inviolable "mobile smartphone" reality that we can rely on. On the other hand, 30em is a readable column width regardless of the surrounding pixel complexities.
We’re moving further into a world where content is king, and we know it needs to "flow like water." The containers we build to hold it can likewise be based on the proportions of the content itself. Ideal line lengths, space to breathe around text—those are things most naturally derived by using units tied to the text itself. Ems.
The fact that baseline ems tend to be loosely tied to pixels, i.e.: 1em ~= 16px ~= 14pt should help control freaks to unclench a bit. But, as I’ve been arguing for a while now, that control is illusory anyway. Your content has already broken free of its jail cell. You just might not know it yet.
In his talk at Breaking Development Orlando, Ethan Marcotte (the Great Father of Responsive Web Design) mentioned his support for em-based media queries going forward. While he didn’t delve into the specifics of his reasoning, my hunch is that his motives are generally in line with this notion: content first.
So, I’ve done some of the convolutions. I’ve tried to understand exactly what a pixel is in a zoomed viewport on a pixel-dense device vis-a-vis its CSS-to-device pixel ratio. I’m done with that for now. Long live ems.
Sitepoint also says relative. This may be an artifact of both MDN and Sitepoint referencing CSS2.1. This change doc appears to represent the switch between relative (2.1) and fixed (3). I dunno. I can’t really make a whole lot of sense of it.↩
Tomorrow (Tuesday, April 3, 2012) at 10AM Pacific, Jason and I will be presenting “The Mobile Omnivore: A Taste Test of Mobile Website Development” on O’Reilly. The 60-minute webcast will include a 35-minute (ish) presentation, followed by audience Q&A.
Synposis
The mobile web is a complex place. There are lots of ways to build a mobile website—how do you choose the right tool for the job?
In this webcast presentation, we touch on a series of technologies and techniques including:
Responsive Web Design (RWD)
Mobile-first RWD
Server-side device detection
HTML5 and CSS3 on mobile
Device idiosyncrasies
Some of our favorite tools and tips for mobile development
Who is this webcast for?
If you already have web development chops but want to go mobile, this is the talk for you! Familiarity with HTML and CSS is a must; comfort with some JavaScript is helpful.
Register Now!
The webcast is free. Register now—we’ll see you there!
Resource Links
Here are some links to some of the topics and tools we talk about in our presentation.
A core tenet of Responsive Web Design (RWD) is fluidity and proportion. Instead of using fixed-width layouts, we enlightened web devs and designers use percentages in our CSS. Font units aren’t pixels or points anymore, they’re percentages (typically for top-level baseline reset) or, more often, ems. And yet the vast majority of us still write width-based media queries in pixels, e.g.:
@media all and (min-width: 500px) {}
@media screen and (max-width: 800px) {}
It’s a natural thought process: for windows or screens of particular width ranges, we want to flow our content in a particular way. This naturally seems like a pixel dimension. But, once again, to bring out my big hammer, what about when we look at things from a content perspective?
Folks who design for traditional reading media—where the content really is king—don’t center design decisions around the absolute width of content-holding elements so much as around the optimal line lengths for the content they’re flowing. There are some tried-and-true numbers one can shoot for that make for the “right” number of letters (and thus words) per line for comfortable human reading.
Thus actual column width is a function of font size and ems-per-line.
Baseline expectations
You may have seen the rule of thumb (useful, admittedly!) that makes the following general equation in terms of baseline font sizes in CSS:
100% = 1 em ~= 16px ~= 14pt
This means that, at your baseline, that is, before you’ve adjust font sizes in any child elements, the default font size in the browser is usually approximately 16px and usually approximately 14pt but always 100% and 1em.
If we start from a baseline of 16px, you may well wonder what the difference (beyond academic) is between a media query like:
@media all and (min-width: 400px)
and one like this, that uses ems multiplied against the 16px baseline approximation:
@media all and (min-width: 25em)
The answer, my friend, is content
Here’s the 64-dollar question or whatever:
What happens when the baseline is not 14pt/16px?
On Ye Olde Desktop Web, this situation most often comes about (“most often” is unscientific here, but I’m willing to toss out the hypothesis, at least) from user-intiated zoom in browsers. Low-sight users might do it, I know I do it when I’m surfing the web on my Mac Mini from the couch across the room. I’m not that old but, man, it’s hard to see the contents of a Wikipedia article on a 23″ monitor from 10 feet away.
As I zoom in, that is, make the text larger in my browser, I’m no longer at a 14pt/16px baseline. 100%/1em in my world is now a different number, maybe 18pt, maybe 32px. Pixel-defined content holders no longer have comfortable amounts of words per line. Pixel-defined content holders that float might wrap awkwardly as the content in them swells.
Case study: Our nav
Our creative director and CSS wizard extraordinaire, Aileen, whipped us up a beaut of a responsive new site layout. For various screen widths, our site’s nav has a few different behaviors.
In pixels at normal zoom, the nav elements fit in a line roughly at a width of around 656px. There’s generous room to detatch and float next to the logo at around 960px.
For screens/windows narrow enough that the full set of top-level nav elements would not fit on one line, we use the menu button nav pattern:
For screens/windows in a particular range that are wide enough to fit the top-level nav elements on a single line, we do that.
For screens/windows wide enough to fit all of the top-level nav elements horizontally and have enough room left over for our logo, we detatch and float the nav to the top right.
But what happens if a user has his or her zoom set higher?
I’ll show you a little experiment. I’m using the Chrome browser, and I’m viewing our site with a window about 670 pixels wide. With a pixel-based media query, that puts me in the second category of nav experience: all of the top level items are shown horizontally, docked to the top of the content:
OK, now I’m going to use the Zoom In command twice to make my text larger.
With a pixel-based media query:
With an em-based media query:
Why did this happen?
The pixel-based media query @media all and (min-width:656px) still evaluates to true with the zoomed-in text and therefore creates awkwardly-wrapped nav elements.
However, the em-based media query of @media all and (min-width: 41em) scales to the larger text size. Zoomed in like this, the browser no longer satisfies that query: we have fewer than 41ems to work with. So we deliver the menu-button nav pattern and other layout and styling appropriate for the way the text fits. Content, again, is what ends up dictating what we’re doing in the end.
You could also make the text smaller and watch the same proportional adjustments occur, in the inverse.
BTW: It should be noted that, unlike window resizes, which cause media queries to be re-evaluated immediately, you’ll need to reload the current page if you zoom in or out for em-based media queries to re-apply. My hunch is that most users who zoom a lot keep their zoom set as they navigate around different pages and aren’t changing zoom settings on a site-by-site basis. I could be wrong about that, though.
The specifics of em-based media queries
The media queries on our site are all crafted based on the approximate baseline. We played with our browser window widths, adjusting them until it looked like they were at the appropriate width to create a breakpoint at normal text zoom. We noted that pixel measurement and divided it by the rough baseline of 16px to arrive at our em units. There may well be a better way to do this math, but this seems to do the trick so far.
A device-specific aside
One of the things that spurred me toward thinking about em-based media queries was my own Kindle Touch. Through no action of my own, the Kindle browser’s default text zoom is, roughly put, high. Like newer smartphones, the Kindle has a high pixel density, 167ppi. An absolute-sized font (say, 16px) on a high-density screen is correspondingly tiny. Most smartphone browsers get around this by reporting their resolution differently for purposes of the web. An iPhone 4, for example, which has a real resolution of 640×960 and 326ppi, masquerades as 320×480 in the browser as a way to get normally-designed websites to look normally-sized and not teeny tiny. For the iPhone, 1em is still approximately 16px or 14pt, and so pixel-based media queries generally behave equivalently to em-based ones (disclaimer: that’s a broad generalization).
The Kindle Touch, on the other hand, has taken a different approach. It reports its web pixel resolution as 600×800, but its default text size is considerably larger than 16px/14pt.
Our early, pixel-based media queries for our nav looked dreadful on the Kindle. Its resolution meant that it was using our tablet-range layout, but its text was enormous, causing widespread ugliness as the pixel-width elements didn’t scale to adjust. The site looks pretty decent, however, with media queries in ems:
Our site looks tolerable on a Kindle Touch. That’s about as good as it’s going to get on that browser.
Sadly, I did find that, as reported by Stephanie and Bryan Rieger, the Kindle considers itself to be in color, so the media query @media all and (monochrome) doesn’t match it and @media all and (color)does. Too bad! Speaking of Kindle and Stephanie Rieger, the Kindle Fire tablet’s browser is also a great cautionary tale about mistaken complacence about “standard” device screen widths like 480, here is an enlightening tweet:
Food for thought, Stephanie, food for thought…
p.s. Thanks to the observant folks in the community who have noticed that our nav, at wider widths, has drop-down elements that are not ideal in terms of usability. We‘re cooking up ideas about how to make this better! have actually made improvements to the tablet-version nav on touch devices since I started working on this post! More to come in Nav-Land.
Interested in the topics discussed in our blog? Looking for a more foundational guide to the mobile Web? Check out the book we wrote.
Head First Mobile Web is written for web developers by web developers, with clear explanations and hand-on examples that get you working with real code, quickly.
Over the last few months, I’ve been proud to represent Portland as the 
We wrote the book:
Recent Comments