I normally don’t write a post simply to link to another article, but if you’ve enjoyed the things I’ve written about responsive images, you really should read what Eric Portis wrote about Srcset and Sizes.
Eric describes the logic behind srcset and sizes, how they are part of the new picture proposed standard, and how to use them.
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.
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.
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:
…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.
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?