It’s hard to believe it’s been almost three years since the publication of Ethan Marcotte’s seminal Responsive Web Design article on A List Apart. The ideas and techniques described therein blew our minds while forcing us to drastically reconsider our design processes. Even today, the struggle continues to determine which design deliverables make sense in a post-PSD era.
Personally, I dig Dave Rupert’s idea of “Tiny Bootstraps, for Every Client”:
Responsive deliverables should look a lot like fully-functioning Twitter Bootstrap-style systems custom tailored for your clients’ needs. These living code samples are self-documenting style guides that extend to accommodate a client’s needs as well as the needs of the ever-evolving multi-device web.
The whole post is great, and it got me thinking… along with solid content strategy, design and engineering processes, what steps can we take to insure our “tiny bootstraps” are comprehensive enough to remain relevant and useful long after launch?
Cue Jason with a cool idea: We could document patterns in existing frameworks. A list of what’s typically included might serve as a good starting point, something to measure our client deliverables against to make sure we haven’t overlooked anything obvious.
In which I willingly make a spreadsheet
I combed through a (non-exhaustive) collection of suitably broad or noteworthy links from Anna Debenham‘s list of front end styleguides and pattern libraries, recording instances of observed patterns and adding new ones as necessary. I skipped over anything that seemed too idiosyncratic, and grouped elements of similar intent even if their description or implementation differed.
I found this to be a worthwhile exercise. It helped me wrap my head around the elastic scope of a “tiny bootstrap.”
I thought there’d be more overlap between frameworks than there is. I recorded over 160 distinct patterns, none of them ubiquitous. Some came pretty close, especially headings 2 through 4, typographic elements and pre-HTML5 form elements. No single framework included even half of the total recorded patterns (Bootstrap had the most).
Sometimes the most infrequent elements surprised me with how obvious they seemed in retrospect. For example, color guides and font stacks only occur in a couple of places.
The thought of maintaining the document indefinitely makes me queasy, but I’ve already started referring to it frequently. I’d love to know if anyone finds it as interesting or useful as I have.
I agree. Back in 2011, I wrote that Google needed to step up. Thankfully, they have. Chrome for Mobile is a great browser.
But Chrome for Mobile is still a small percentage of what people on Android devices are using. A lot of this has to do with the fact that older versions of Android that cannot run Chrome still account for 44.1% of Android’s installed base.
Last month at the Breaking Development conference, many of the speakers talked about large installed base of Android browsers as being an impediment to pushing the web forward on mobile. The discussion reminded me of the efforts that the web community undertook to convince users to move off of IE6.
Web developers started encouraging users to upgrade to a newer version. Microsoft helped out by creating the IE6 Countdown web site which helped web developers figure out when IE6’s market share had gotten low enough that they no longer had to worry about it.
I’ve thought a few times about how we should encourage Android users to upgrade their browsers, but in this case, there is no way for them to update to a new version of the Android browser and they can’t install Chrome on any device not running Android 4.x.
But while discussing this at Breaking Development, it was pointed out to me that even if people cannot update their browser to Chrome, many do have other options. They can install Opera Mobile or Firefox.
Maybe it is time to change our mindset towards the Android 2.x Browsers and instead of working around its many limitations, perhaps we should actively encourage people to switch to a better browser.
What had Bruce said that blew my mind? It was the fact that you can embed media queries inside SVG images.
Maybe this is common knowledge for everyone else, but I was stunned by the news. Today I finally got a moment to research this further and found this fantastic video from Andreas Bovens showing off media queries in SVG.
I recommend starting the video at the 3 minute 25 second mark.
The really cool thing about the way media queries work inside SVG is that they react to the viewport of the image itself, not the viewport of the browser. This means you can make decisions about how an image should look at different sizes without needing to know how that image will be used in a given page.
Here is the source from one of the example images that Andreas uses:
As long as I’m posting puzzles, riddle me this: what happens to the browser’s lookahead pre-parser if we find the holy grail of responsive images—an image format that works for all resolutions?
What is the holy grail responsive image format?
In nearly every discussion about responsive images, the conversation eventually turns to the idea that what we really need is a new image format that would contain all of the resolutions of a given image.
A solution like this would be ideal for responsive images. One image file that can be used regardless of the size the image is in the page. The browser only downloads what it needs and nothing more.
As Ian Hickson recently wrote on the WhatWG mailing list regarding future srcset syntax complexities that might come with hypothetical 4x displays:
Or maybe by then we’ll have figured out an image format that magically does the right thing for any particular render width, and we can just do:
<img src="jupiter-holiday-home.smf">
…and not have to worry about any of this.
It seems that no matter where you’d like to see responsive images go—srcset, picture, whatever—that everyone agrees we’d all be happier with a new, magical image format.
The end of image breakpoints for most responsive images
If this mythical image format existed and was adopted by browsers, it would mean the end of image breakpoints for most responsive images. You can see this in Ian Hickson’s hypothetical code above.
Unless the image required editing at various viewport widths (see art direction use case), the document author could simply point to a single file and know that the browser would download the data necessary to display the image for anything from a small mobile screen to a large, high-density display.
How do we reconcile a pre-parser that wants to know what size image to download ahead of time with an image technique that wants to respond to its environment once the page layout has been calculated?
Image breakpoints are designed to give the lookahead pre-parser the information it needs to pick the right image before the browser knows the size of the element in the layout. This is how we get around the problem.
But we just saw that image breakpoints would go away if we had a new, magical image format. Without the image breakpoints and without knowing the size of the image in the page, how would the browser know when to stop downloading the image?
Unless I’m missing something, it wouldn’t. The browser would start downloading the image file and would only stop once the layout had been determined. In the meantime, it may download a lot more data for a given image than is necessary.
Flickr example
Let’s take a look at Flickr as an example. Flickr would be a huge beneficiary of a new image format. Right now, Flickr maintains a bunch of different sizes of images in addition to the original source image.
Instead of having to resize every image, Flickr could use a single image format no matter where the image was used throughout the site.
Lets also assume that in this future world, Flickr was responsive design using flexible images so that the size of an image is dependent on the width of the viewport. What happens to a typical Flickr layout like the one below?
Because it would be a responsive design, the size of the thumbnails on the page will vary based on the screen size. But no matter how big the thumbnails got, they would never equal the full size of the original image which means that the browser would need to stop downloading the magic image file at some point or it would download extra data.
What would the lookahead pre-parser know at the moment it started downloading the images? All it would know is the size of the viewport and the display density.
Based on those two data points, the pre-parser might try to determine when to stop downloading the image based on the maximum size the display could support. That works ok if the display is small, but on a large, high density display, the maximum image could be gigantic.
And because our magical file format would contain multiple resolutions, the browser would likely keep downloading image data until the layout was calculated making it very likely excess image data would be downloaded and the download of other assets would be delayed.
Responsive images versus the lookahead pre-parser
Of course, this is all hypothetical. We don’t have a magical image format on the table. So for now we can avoid resolving what I see as a central conflict between the need for the pre-parser to start speculatively downloading images before it knows the layout of the page and the fact that the size of responsive images isn’t known until the page layout is determined.
But in the long run—if we find our holy grail—this conflict is likely to resurface which makes me wonder about our current efforts.
And at the same time, I can’t help but wonder, if we all want this magical image format and if in some ways it seems inevitable, then are we jumping through hoops to save browser behavior that won’t work in the long run regardless?
For a few months now, I’ve been puzzling over the question of how to pick responsive images breakpoints. It has become a koan to me—no more answerable than the sound of one hand clapping. And as long as I’m haunted by the question, I thought I would share the joy.
What responsive images am I talking about
First, let’s make sure we’re talking about the same thing. In this case, when I refer to responsive images, I’m not talking about:
An image that is edited depending on the size of the screen. (what I previously called the art direction use case.1)
Different images for different display densities.
What I am talking about is:
Selecting different image files with different resolutions of the same image based on the screen size.
A desire to provide these different image files so that a browser doesn’t download an unnecessarily large file.
Basically, the classic use case that got us all looking at responsive images in the first place.
Defining image breakpoints
In responsive designs, we refer to breakpoints as the screen widths at which media queries are used to make changes to the layout. These breakpoints should be determined by the content, not by common device dimensions.
Image breakpoints are similar. What are the screen widths at which you switch from one image file to another?
Shouldn’t image and responsive design breakpoints be the same?
Not necessarily. If we were talking about the art direction use case, then it is likely that the breakpoints would be the same because changes in the layout might also indicate an edit to the image.
But in the case where we’re simply changing files to provide different resolutions and a faster download, the image breakpoints should be determined based on when the browser is downloading an unnecessarily large file.
In the responsive layouts I’ve worked on, content image sizes and their breakpoints were chosen for completely different reasons than the design (CSS) breakpoints: the former for sensible jumps in file size to match screen dimension and/or density, and the latter for how content modules are visibly designed at given viewport dimensions.
Design breakpoints can be plentiful, especially when factoring in all the minor and major tweaks in multi-column responsive layout. Yet for content images, I’ve found the need for fewer breakpoints, or even entirely different breakpoints than the design. In a site like the bostonglobe.com for example, 2-3 image sizes provide sensible jumps in file size, and because the images live a fluid layout, they scale to fill the layout gaps as the CSS breakpoints shift much more frequently around them.
So unless the image is changing in coordination with layout changes, the breakpoints for images do not need to coincide with the breakpoints for layout. In fact, coordinating them may be less ideal.
So how do we pick “sensible jumps in file size”?
This is the question that has been troubling me. If we’re going to tell people creating responsive designs that they shouldn’t tie their image breakpoints to their designs, what guidance can we give them on how many file sizes make sense and when should they switch to a different file size?
To wit, how do you determine what is an unnecessarily large file? Is that 1 byte? 10k? 20k?
And if you can answer that question, how do you determine the resolutions at which those file size jumps are going to occur? Depending on the content of an image and the compression algorithm used, images are likely to have different resolutions at which they experience significant changes in file size.
On a large site with a mixture of gif, png, and jpg images, can you pick common image breakpoints? If so, how?
The problem is there is nothing intrinsic to the image that would guide you in deciding where you should switch from one size of the image to another. Whatever we select will be entirely arbitrary unless we base it on our design breakpoints.
And basing our image breakpoints on our design breakpoints is not ideal.
The correctly sized image
The only thing we can absolutely say about what size image should be used for a given screen size is that the ideal solution is one where the resolution of the image matches precisely the size that the image is in the page.
Of course, this isn’t practical unless we have find the holy grail of responsive images—a magical new image format where a single file provides all resolutions and the browser only has to download what it needs to fill the space on the page. And even if we find the format, we’d have to hope it wasn’t legally encumbered and that all of the browser makers could agree on it.2
In the meantime, I’m stuck pondering the question of what to tell people when they ask how many image sizes and what breakpoints should they use in their responsive designs.
If you have ideas, I’m all ears. But please explain how you come to that conclusion and how you would advise another designer, on a different project, to figure out what image breakpoints would make sense for them.
Stephen Hay and I have been discussing how art direction may be misused as a label for this use case. We’ve been discussing different names for it, but haven’t settled on anything yet.
The easiest thing to do in discussions about issues like this is to insist that we need a new image format. I understand the sentiment and if I had a magic wand, I’d make it happen. But until someone—and by someone I mean a large company with intellectual property and lawyers to back it up—steps forward to volunteer a new image format for consideration, we’re stuck with the cards we’ve been dealt. That means that sooner or later, we’re all going to be trying to figure out how to decide where to set image breakpoints.
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.
I combed through a (non-exhaustive) collection of suitably broad or noteworthy links from Anna Debenham‘s list of front end styleguides and pattern libraries, recording instances of observed patterns and adding new ones as necessary. I skipped over anything that seemed too idiosyncratic, and grouped elements of similar intent even if their description or implementation differed.
We wrote the book:
Recent Comments