Among the developers at Fresh Tilled Soil there’s been a lot of talk lately about dealing with the problem of responsive images in flexible site design. The method advocated by Ethan Marcotte in his book is well known and should be the basis for any responsive image solution. In short, setting the CSS max-width property to 100% allows the image to flex and fill its parent container. However, there are some other issues which aren’t addressed by this method.
One of those issues is bandwidth. Loading a full-sized image that is shrunk down for smaller sites will always yield an image of acceptable quality, but on smaller devices with less bandwidth you want to avoid loading resources that aren’t necessary. A HiDPI-optimized image is extreme overkill for a smartphone, and will destroy your page load times. Users aren’t interested in waiting around because you like Retina displays and you’re too lazy to optimize for older screens and devices.
One of the solutions that’s been kicked around lately is the creation of a new element, the
<picture> element, which works in a similar manner to the HTML5
<audio> elements. The idea is that it will accept multiple sources, along with attributes in a syntax similar to media queries that will determine which image is loaded based on device size. It’s not a real element yet, but the creators have written a polyfill so you can start using it today.
<picture> element is a great idea, but it works off of one bold assumption: small devices have little bandwidth, large devices have a lot of bandwidth. This may be typical, but it’s certainly not enough of a set-in-stone rule for the comfort of a good developer. A good solution needs to consider several factors, including screen size, pixel density and available bandwidth.
This morning I found a beta service that may be the answer to this problem. It’s a site called ReSRC.it and it purports to solve all of the problems we’ve been trying to solve. I have to dig into the documentation and see how it works before I can offer any sort of recommendation, but I think it’s worth exploring just because the people behind it are trying to solve the bandwidth problem along with the issues other solutions are trying to solve. I’m curious to see what kind of job they’ve done.
A caveat: one reason the
<picture> element has received so much support is because it’s a markup-based solution. The developers behind it think that because it’s an issue of what content is served the problem should be solved client-side instead of server-side. I agree with this from the standpoint of theoretical purity, and I think work should continue on the idea. But for now, we need a solution that works, and that solution just may be the ReSRC.it service.