Responsive Design has become vital in the age of mobile browsing, and images have been a key source of frustration for designers who wish to increase the speed and functionality of their sites. Soon, though, all that will change, as the <picture> element in HTML5 takes off starting later this year.
The new <picture> element will act as a filter for the existing <img> tag. This will allow for older browsers to still load <img> images even if they don’t recognize the <picture> tag, but will also allow newer browsers to filter content based on different conditions. According to Scott Gilbertson in his post "A Complete Guide to the Element":
<picture>element looks a bit like the HTML5
<video>tags. The actual
<picture>tag acts as a container element for
<source>elements which then points to the actual images you want to load.
The big difference is that
<picture>doesn’t actually load your image. For that you need an
<img>tag. So the browser evaluates all the various attributes you’ve specified in your
<picture>block, picks the best image and then loads the image into the
The <picture> tag will be helpful in a number of use cases: for example, adjusting which image is loaded based on the resolution of the user’s screen. Gilbertson demonstrates with the following example:
Let’s say we’re trying to build a more responsive version of my Responsive Web Design book page. Let’s say we have two book cover images —
cover1x.jpg, which is a normal resolution image, and
cover2x.jpgwhich is the same image, but at a much higher resolution.
Let’s go ahead and make things future-friendly by adding a third image,
cover4x.jpg, to handle those 4K+ monitors that are just a few years away from being on every desktop. So with three images at three resolutions our
<picture>code would look like this:<picture> <source srcset=”cover1x.jpg 1x, cover2x.jpg 2x, cover4x.jpg 4x”> <img src=”cover1x.jpg” alt=”Responsive Web Design cover”> </picture>
Here we have a simple
<picture>tag with one
<source>tag and an
<img>tag which doubles as a fall back for older browsers. Within the
<source>tag we’ve used the
srcsetattribute to say to the browser (or “user-agent” in spec-speak) if the screen pixel density is 1x then load
cover1x.jpg; if the screen density is 2x then load the higher-resolution
cover2x.jpg. Finally, if the screen density is 4x, grab
Still, the browser has the last word on which image is loaded, as it may have more information about the user’s needs and preferences. Gilbertson explains:
It may be that, despite having a high-res screen, the user has explicitly instructed the browser (through a preference setting) not to download large images over 3G.
Screen resolution is after all just one factor in deciding on the appropriate image to download. As developers we don’t (and never will) have all the information that the browser does, which is why the final decision lies with the browser. As I’ve said before, this is a good thing; this is exactly the way it should be.
The <picture> element should be working on stable versions of Firefox and Chrome by the end of this year – including the mobile versions of these browsers. Opera is likely to support it at that time as well.
The <picture> element should solve many of the current problems with responsive images and allow for faster and more intuitive web pages.