Steve Fenton

<< May | June | July >>

Monday, 4th June 2012

Responsive images is a proposed feature for HTML5 that would allow different images to be served depending on various factors. There is currently plenty of discussion on responsive images but, so far, no really good solution to the problem.

The reason for the difficulty in coming up with a solution is because there isn't a single problem. There are three.

People want to be able to serve different images based on the size of the browser. This can be to preserve the design at different sizes or to provide carefully re-sized images rather than allowing the browser to adjust the image.

There is also a requirement to save mobile browsers bandwidth by giving them a low-resolution image, thus speeding up the page load on mobile phones and saving people money if they pay for data.

Finally, there is a case that says you might want to send very high definition images to high-density displays to take advantage of the extra pixels.

So why is it so difficult to meet these three requirements?

There is the additional complication of having to come up with a solution that will give us the features we need, while also working in today's (and yesterday's) browsers. This is really one of the toughest parts of the challenge.

The additional problem comes from a general confusion about what should be responsible for responsible images. CSS should just be for style, not for content. HTML should be for content, not for style. Are responsive images style, content or both?

Personally, I would rather see the whole concept of responsive images removed from CSS and HTML and pushed into the request headers sent by the user-agent to the server. The information we need to know is screen size, pixel density and bandwidth, so send some information to the server about these things.

There is of course one problem with sending this information - if you send the exact information about size, resolution and speed, along with all of the existing information that is sent in the request, you would probably be able to identify a user with this information. For example, how many people would have the exact same combination of request headers?

To combat this, the information could be generalised, so the information could be divided into groups to make the information less identifiable and the user agent could allow the user to set their privacy settings or a default profile.Instead of exact numbers, bandwidth could be grouped as follows (illustration only):

1. Below 100kb
2. 100kb - 1mb
3. 1mb - 5mb
4. 5-mb - 10mb

So you would be told that bandwidth is "1", and could choose to serve a smaller image. If you received a 6, you would know that you have greater than 10mb, even though at first draft the 6 may not be defined.

The beauty of having this on the server is that you can server a single, correct image in the first instance that would work in any browser, because even if the request headers were entirely absent, you could choose to server a default image.

It doesn't stop there either! Your HTML would be smaller, because you don't have a stack of source tags with attributes to describe when they should be used, which in some cases would probably cost more bandwidth than they save.

And finally, there are already a myriad ways to get from these request headers to an image source using a HTTP handler, server-side script or even using an edge server that does it all for you.