Responsive Web Design, Part 2 (2015)

Responsive Images

Image Format Fallback

One more thing you may want to do with images (not necessarily responsive ones) is to serve different file formats to different browsers, according to browser support for them. As well as traditional file formats that browsers support (PNG, JPEG and GIF), there are several newer file formats that browser vendors are trying to encourage developers to use. These formats usually perform better than the traditional ones, since they include all kinds of algorithmic improvements that make image compression more efficient. Specifically, Google is pushing the WebP¹⁷ format and Microsoft is promoting JPEG-XR¹⁸.

Unfortunately, these new formats lack the traditional formats’ level of ubiquitous support, which means if you serve these formats as your <img src> value, even though the browsers that support them will exhibit an improved user experience, the ones that don’t won’t show any image at all. That’s hardly good.

Up until today, the only way to serve such formats without breaking the user experience in non-supporting browsers was content-negotiation, using the Accept HTTP header or UA sniffing. While that mostly works fine, there are some caveats. It requires server-side fiddling, which some developers can’t do, or aren’t interested in doing; and it also introduces difficulties with making these images publicly cacheable.

With the <picture> syntax, we finally have a way to define a client-side fallback mechanism. By using the type attribute on <source> we can provide the browser with multiple image URLs, and let browsers pick the one they support. Such mechanisms have been available for other resource types for years (e.g. fonts and videos). Now a fallback mechanism is also available for images.

The syntax for client-side format fallback looks something like:

</picture>

Just as we’ve seen for media, browsers go over the various <source> elements and pick the first one that matches; that is, the first one which has a supported image MIME type as the value of its type attribute.

Accessibility

As far as accessibility goes, that’s easy. Nothing has changed in image accessibility with the introduction of srcset, sizes and <picture>. Since srcset and <picture> are simply enhancements of the <img> element, browsers can continue to use the good old alt attribute inside of <img> and get the text alternative to the image from the attribute’s value.

Some people have called¹⁹ for support of multiple alt values and multiple figcaption values that depend on the picked resource. For now the consensus within the RICG is that such usage is an edge case and is best addressed using JavaScript. If this is something you need to do, there’s a prollyfill (a polyfill for a not yet standard API) called picturecaption²⁰ that can let you do just that.