Responsive Images for HTML5

Responsive Images for HTML5:
The HTML image tag has been around about as long as HTML itself. In nearly 20 years the tag has changed very little, in spite of the essential role that images play in most Web content. During that same period of time, the capabilities of the devices people use to view Web content have changed dramatically. For the longest time Web content seemed to assume a world where color displays had a pixel density of roughly 96 dpi and a viewing area of about a million pixels. This fiction persisted much longer than it should have because it’s just easier to target one kind of display. In the past five years or so, reality has intruded. Web developers must now deliver content that looks good on relatively huge desktop displays and televisions, as well as relatively small phones and tablets with pixel densities of 150 dpi or more. The resolution of Apple’s eye popping Retina displays can be over 300dpi, roughly the same as their original (monochrome) laser printer. All of this power and diversity creates some problems for the old HTML IMG tag:

• Authors would like to specify different images, depending on size of the available screen real-estate


• Similarly, authors would like to specify different (bigger) images for high-pixel-density displays


• Authors would also like to be able to specify alternative images when the available bandwidth is low


• Sometimes “different” just refers to an image’s size, sometimes it’s how the image is cropped

JavaScript Solutions, Preloading

One can overcome many of these problems by writing JavaScript that tries to do the right thing in light of the characteristics of the display the page has landed on. Unfortunately, doing so runs afoul of a browser feature called “preloading”. Downloading, parsing, and executing a Web page requires a great deal of waiting. Modern browsers fill this time by eagerly preloading various elements, notably images. This makes the overall process of displaying a new page go much faster. Users love this. It makes the Web feel more “responsive”. So if we want a solution that’s also responsive to the wide variety of modern displays, we have to be careful not to create an image preloading obstacle.

Debate About an HTML Solution

In roughly the past twelve months there has been a great deal of discussion about exactly how to support “responsive images”; about the best way to deal with the problems listed above. Several solutions have been proposed and championed – notably a new picture element – and many expert Web authors and browser implementers weighed in via email, forums, blogs, on IRC, and probably in person. Finally in May, a new IMG tag attribute called “srcset” made its debut in the WhatWG HTML5 spec. If you’d like to review the rationale for this particular solution, you might start with the WhatWG email archive. Similar support for CSS images has also been proposed. In fact the CSS image-set function recently made its debut in WebKit.

New HTML IMG Attribute: srcset

The new srcset IMG attribute enables specifying a set of images to handle displays of different sizes and pixel densities. The value of the srcset attribute is a specially formatted string that enumerates the URLs for a set of alternative images, the pixel density of the display they’re intended for, and the maximum viewport size they’re intended for. The string itself is a comma separated list of image URLs followed by optional size and pixel density qualifiers. The srcset syntax is easiest to explain with a few examples:

<img alt="robots" srcset="robots.jpg 1x, robots-HD.jpg 2x">

In this case we’ve specified two versions of an image, “robots-HD.jpg” for double-density displays and “robots.jpg” for regular displays. The IMG src attribute is now equivalent to specifying a srcset image with (just) “1x”, so this can be shortened slightly to:

<img alt="robots" src="robots.jpg" srcset="robots-HD.jpg 2x">

Here’s a rough approximation to how this srcset example might appear on a pair of screens: a normal pixel density display on the left, and a double density display on the right.

robots.jpg

robots-HD.jpg

The tidy “2x” device pixel density qualifier means that one CSS pixel maps to two device pixels. Typically, when a pair of images is specified in this way, the 2x image is twice as big as the 1x version so that they’ll both occupy the same CSS pixel area. A display screen’s pixel density and its real physcial resolution are only loosely coupled: the 1x and 2x qualifiers are typically integral approximations to the real relative display densities. This is a helpful simplification. For all of the complicated details, you might start with the material about lengths in the latest CSS specification.
Mobile phone screens are much smaller than what’s found on a modern desktops and laptops and connection speeds are likely to be slower, so we’d like to use a smaller and differently cropped image for the small screen scenario:

<img alt="robots" src="robots.jpg"
 srcset="robots-closeup.jpg 600w, robots-closeup-HD.jpg 600w 2x, 
 robots-HD.jpg 2x">

What we’re saying here is that if the viewport’s width is less than or equal to 600 then use robots-closeup.jpg or robots-closeup-HD – depending on the display’s pixel density, otherwise use robots-HD.jpg for double density displays, and use “robots.jpg” for everything else. To specify the maximum viewport size we use “w” and “h” to identify width and height qualifiers. For example to specify both: “robots-closeup.jpg 400w 600h”. Exactly what’s meant by the width and height qualifiers bears some explanation.

robots-closeup.jpg

robots-closeup-HD.jpg

IMG srcset Viewport Size Qualifiers

An IMG srcset qualifier like “600w” means that the image is to be used if the viewport’s width, in CSS pixels, is less than 600. The viewport’s size is essentially the size of the visible part of the browser’s content window and it’s also defined in terms of CSS pixels. If you resize the browser window or zoom – and users zoom in and out a great deal on small displays – then the viewport’s size changes. When the user zooms in, the CSS pixel width and height of the viewport get smaller, even though the device pixel size of the browser’s content area does not. Similarly, when the user zooms out, the size of the viewport in terms of CSS pixels gets bigger. Changes in the size of the viewport cause the srcset to be reevaluated, and may cause a different image URL to be selected.
It’s significant that you cannot qualify the viewport’s size in terms of other units, like ems or inches, and you cannot qualify the viewport’s size in terms of the space it’s allocated after layout. This is to avoid creating any obstacles for the image preloader, which will go about its business long before the CSS cascade and layout have run to completion.

The Road Ahead

There are still some outstanding issues with the IMG srcset proposal and debates about how to make images “responsive” still flare up now and then. For example, specifying images based on the viewport size implies that authors need to predict the effect of the viewport’s size on their layout accurately enough to know how much space will be allocated for each image. And there’s still no solution for providing alternative images based on network connection bandwidth and latency.
The next step for this HTML feature is implementation in browsers, or “user agents” as they’re properly called. One can experiment with the syntax using a JavaScript implementation, like this one written by Boris Smus, and hopefully experimental browser versions will start to debut in the coming months. It’s quite possible that during this shakeout period, the srcset feature’s specification will evolve.
Here at Adobe’s Web Platform group we are happy to see that the debate about standard support for responsive images is making progress, maybe even drawing to a close. This seems like a good time for experimental browser implementations to bow, so that Web authors can take the feature out for a test drive and tool developers like Adobe can start adding support for this much needed feature.

Note Also: The Robots

I’d like to thank Richard Muller and GuyRobot.com for the robot photos.

DIGITAL JUICE