HTML5 adaptive images: end of round one

by .

After The Great Vendor Prefix Hullaballoo of April 2012 comes The Great Responsive Images Brouhaha of May 2012.

Adaptive images are the next unsolved mystery of Responsive Web Design. Do you send large high-res images suitable for retina dispays, which are scaled down on smaller, lower res devices and which therefore waste bandwidth? Or do you send low-res images, whch look grotty when scaled up to large screens or high-res displays? Authors have had to rely on elaborate hacks to send different content images (that is <img> in HTML rather than CSS background images) to different types of devices.

By November 2011, I was so frustrated that no specification body was considering the problem that I proposed a strawman <picture> element that re-used the mechanism of HTML5 <video> with its media queries to swap in different source files:

<picture alt="angry pirate">
   <source src=hires.png media="min-width:800px">
   <source src=midres.png media="min-width:480px">
   <source src=lores.png>
      <!-- fallback for browsers without support -->
      <img src=midres.png alt="angry pirate">

Around the same time, others independently came to the same idea and were advised to set up a W3C community group to discuss it which they did. However, in January, the HTML5 editor, Ian Hickson, had said

What’s the use case for doing it for images in <img> elements? Typically <img> elements are for content images, where you don’t usually want to adapt anything.

Those web authors in the W3C Resposive Images Community Group soldiered on in frustration that they were they being ignored because the problem itself wasn’t seen as a problem. Then this week, Edward O’Connor of Apple suggested another method, using a new srcset attribute on the <img> element. This complemented a similar suggestion of his from February for img-set in CSS that is already being added to WebKit:

<img src="foo-lores.jpg"
     srcset="foo-hires.jpg 2x, foo-superduperhires.jpg 6.5x"
     alt="decent alt text for foo.">

The numbers “2″ and “6.5x” tell the browser the relative resolutions; foo-hires.jpg is 2x the resolution of foo-lores.jpg.

Only a few days later, a variant of Apple’s suggestion was added to the spec.

There are two major differences between <picture> and srcset. The most obvious is that srcset uses the <img> element, which is great because that’s the natural place for images, adaptive or not. (You can’t re-use the <video> + <source> pattern with <img> because it is an empty element so can’t have child elements. O’Connor’s solution uses attributes, which are fine.)

The other major difference is that it doesn’t use Media Queries. With Media Queries, the author is reponsible for thinking up every permuations of viewport size, orientation, dpi, colour depth, aspect ratio and the like, deciding how to cater for them (if at all), identifing the breakpoints and coding them up. This requires a lot of consideration by the author, and makes for verbose code; a page with 20 pictures, each with 5 Media Queries on 5 <source> elements quickly becomes a lot of code.

O’Connor wrote

Why provide a scale factor and not a media query? Well, media queries are claims about UA state, whereas here we’re asserting something about the relationship between the image assets. Also, User Agents should be free to use whichever asset they deem best suited to their current situation, taking into account not just “media-queriable things” like device resolution but also any scaling applied to the <img> with CSS, its width=”" and height=”" attributes, or even things like the current page zoom level.

I have a lot of sympathy with allowing the browser to make decisions about what it knows of the environment (network speed, latency, pixel density, orientation) to choose the best image for the job. The idea is that the author shouldn’t be expected to anticipate and cater for all those variables. What she can do is describe the things she knows about -the images, their size and pixel density- and the browser will make its choice.

That way, when we’re all living in space and looking a 3D holograms, the proximity to a black hole can be detected by the iDroid3000 device (black holes notoriously cause Web hologram negative timespace inversions) and the right image chosen; we don’t need to invent new media queries for event horizon proximity and retrospectively add it to our websites.

There are two problems with the srcset suggestion. The first is highly subjective, but many feel the same: as it exists in the current, first draft of the spec, the syntax is revolting:

<img src="face-600-200-at-1.jpeg" alt=""
srcset="face-600-200-at-1.jpeg 600w 200h 1x,
face-600-200-at-2.jpeg 600w 200h 2x,
face-icon.png 200w 200h">

Of course, this can be improved, and must be. This isn’t just about aesthetics. If the syntax is too weird, it will be used wrongly. As Dr Remy wrote, “Good to see authors have another microsyntax to learn. It’s not like they had any trouble with vendor-prefixes.”

The second problem is that authors don’t want to relinquish control. There are questions of art direction (see the section headed Do I care about art direction?), and many remain unconvinced that the Apple suggestion addresses that; proponents of srcset are convinced that it does address those use cases.

Debate continues, with a full and frank exchange of views. There are understandably hurt feelings, too, because some of those who laboured in the Community Group feel that their wishes and work have been ignored.

As one of those who proposed <picture>, I have a degree of attachment to it. That’s ego. (In fact, I’d be delighted if it were called the <yayBruce> element, but I’m resigned to the unfairness of life.) But I don’t really care which syntax makes the spec, as long as it addresses the majority of use cases and it is usable by authors. I’m just glad we’re discussing the adaptive image problem at all.

So, get involved. Read the discussions and say your piece. And once the dust has settled and the specification is looking stable, we Doctors will write up our diagnosis.

61 Responses on the article “HTML5 adaptive images: end of round one”

Dmitry Egorov says

I’m sorry, maybe I missed something, but why can’t we just create some module for Apache (nginx, lighttpd whatever) that will detect user’s browser and/or device and respond with the appropriate image file? Maybe it’s just time to attach some handler for JPG’s like we have already for PHP and many others?

Jeremy Keith says

Just to be clear, using srcset, when you write something like:

“myimage.png 600w 200h”

…you’re *not* saying “this image is 600 pixels wide by 200 pixels tall”.

Instead it’s more like a media query, where you’re saying “this image should be used if the *viewport* is at least 600 pixels wide and 200 pixels tall.”

I was confused by this syntax because I initially thought that by writing this:

“myimage.png 2x”

…you’re effectively saying “the image is double-resolution.” But actually what you’re saying is “if the *device* supports double-density, use this image.”

It took me a while to get my head around that.

Nicolas Gallagher says

FWIW, the <picture> element was first proposed back in 2007 on the mailing list. We only repurposed it as part of a wider re-discussion among developers in November 2011. So it’s not really “our” proposal vs “their” proposal; rather a difference of opinions over different approaches that all originated on the mailing list over the course of time.

Those of us involved in the discussions prior to the creation of the CG were pretty clear from the beginning that it wasn’t about tying our flags to the mast of <picture>. It was about surfacing use cases, considerations, and giving the WHATWG a reason to view the problem of “adaptive images” as something worth their consideration. The fact that a proposal (and Scott’s polyfill) was included with everything else is more a consequence of how developers like to do things, and the flaws we discussed with alternatives.

For example, from our discussion at the end of November 2012:


the onus is on us to provide evidence and use cases… to describe the problems that we have no (native) solution to at the moment.


I like the idea of finding a dev, but—and I’m willing to be wrong here—I don’t think we need to arrive with a working solution.

That’s not to say that people (who can handle the mailing list) shouldn’t chime in and help improve the `srcset` proposal by sharing areas of concern on the mailing list.

However, IMO, the bigger issue in this whole set of events is the miscommunication between interested parties. There is the problem of developers getting involved in the mailing lists and feeling talked down to, but there is also a problem with the WHATWG not adequately broadcasting what is going on via channels that developers prefer to consume.

Last night, I had a positive and constructive conversation with Hixie and annevk helped to clarify a lot of things in my mind – If people want to communicate with the WHATWG, then it needs to be done via their channels – the mailing list. If the WHATWG wants to communicate with the wider developer community (it does), then it needs to be done via other channels…but it also needs help doing that.

Hopefully, there is a role for interested parties to work with WHATWG members and filter out parts of the mailing list important for developers and to summarise them on the WHATWG blog/Google+/Twitter etc. A look at their current content shows how disconnected it is from the areas developers are interested in and concerned about.

Paul Irish also informed me that WebKit has a policy of announcing things before they are authored. That might be something that the WHATWG should consider – putting the message out about significant changes and areas of wider developer interest before they are written into the draft.

David Beesley says

Based on Jeremy’s clarification of the syntax. I would go out on a limb and say that Apple’s proposal is a good starting point.
“Here’s a fallback image for browsers that don’t support srcset, now heres the source set of images, and their associated breakpoints/device res” essentially a condensed version of the proposed element (maybe I am missing something).
Works for me, but as Remy has said, the syntax does need tidying up so that it follows a more logical, more “HTMLey” style. I’d imagine the finalised spec will be something of a halfway house between the two current proposals.

Any idea when we will see browsers rolling support out for this? I am keen to have a play with it.

Terence Eden says

I agree that in the ideal world we should be doing this server-side after negotiation with the browser.

However – not all web pages are served from a “server”. Some are just static content with no negotiation – think of pages hosted via DropBox for example.

The other ideal solution is a brand new image format combining the best elements of SVG and progressive JPG. But getting a new format adopted is near impossible – especially with the constraints of backwards compatibility.

I’m not so sure that screen size / resolution is ideal. Someone on a tablet connected over a 2G network may prefer smaller images. Especially if they’re paying per MB.

Matt Wilcox says

Thanks Jeremy for clearing that up – it’s something I did not understand. And it’s weird, against almost any other syntax in HTML I can think of. element properties generally describe properties of the element, not properties of some other thing.

For srcset to be viable it needs to move away from the assumed pixel basis. Responsive layouts can be based on nothing but em’s, for example. Images need to use these units also.

Francisc says


David Goss says

@Jeremy Keith

Damn it.

At first, I thought srcset worked as you describe above. Then, on the WHATWG mailing list, Benjamin Hawkes-Lewis told me that the width and height parameters were not conditions (like media queries), but rather that they were metadata about the image, to be used in the browser’s decision on which image to server. I kept following the thread and as far as I know nobody corrected him. So, I took his word for it, and wrote a post on the Community Group based on it, saying that I now understood how srcset worked, and why I still opposed it.

As you clarify above, my first intepretation was correct, and that’s how it’s gone into the spec.

Drew McLellan says

This is absolutely something that needs to happen client-side, not server side. From a performance point of view, images are commonly served from static servers and CDNs which deliberately have no ability to run logic – they’re all about being light, fast and widely distributed.

Images also need to be cached (often in multiple places, from the browser back), and realistically, that means that a single URL needs to represent a single image version uniquely.

Jeremy Keith says

It turns out that I’m still misunderstanding what’s in the spec.

If you write:

“myimage.png 600w 200h”

…you’re not saying “serve this image if the viewport is at least 600 pixels and at least 200 pixels tall.”

Instead, you’re saying “serve this image if the viewport is *less than* 600 pixels wide and *less than* 200 pixels tall.

I’m really, really concerned about that because it’s going to make it much, much harder to take a mobile-first approach.

Terence Eden says

Have to slightly disagree with you there, Drew. Modern CDNs (like Akamai) do have an ability to run logic. They can even cache pages / images / etc based on user-agent.
Specifically, I’ve used Akamai to serve an image of a different resolution to mobile & desktop. Same URL, different response based on UA.

Not every browser will get updated. Of the billions of smartphones accessing the web today, very few of them will see updates from their manufacturer. That’s why I’d rather see a server-side solution.

I would expect to write something like

<img src="images/bruce" lores-scr="images/bruce-tiny" highres-src="images/large/bigbruce" />

That way, the server can work out which image to serve (and do content negotiation and server phones jpg, png, svg depending on what the the user accepts) – but the browser can specifically look for high or low res images if it has been told to.

(I’m using high & lo as placeholder – sure there’s something more appropriate.)


Ian Devlin says

The fact that Jeremy Keith is struggling to understand what the specification says, what hope do normal (I’m not saying that you’re abnormal Jeremy!) authors have?

Bruce Lawson says

It troubles me, too, that the height and width syntax is pretty much duplicating Media Queries in that it suggests breakpoints to the UA but (presumably) doesn’t require them.

(This idea of hinting isn’t new; it’s part of the functionality of the preload attribute on video and audio).

But if it is doing Media Queries’ job, it should look more like Media Queries.

It also negates the idea of the author describing the assets rather than the circumstances that the UA should use the assets.

John Reading says

I have a problem with the element in that it’s simply too much verbosity. I can’t fathom what a product grid might look like. Regardless of what is the approach, there needs to be a way to tokenize the logic that determines this. Here’s something I proposed that uses the link media=”" that we already use to tokenize the correct src attr.

Dale Cruse says

I plan to make effective use of the <yayBruce> element in all current & future projects.

Josh T. says

I still prefer the <picture> proposal, but the arguments about why we shouldn’t use media queries are good ones, and I haven’t heard them mentioned before I read this.

Why don’t we have a compromise?

<source src="..." set="200w">

With this method, it’s much cleaner and we could still allow the media attribute for those who want it.

DSKrepps says

If I think about what I’d like using the most, I come up with this:

<link rel="alternate src" selector="img[src=lowres.jpg]" media="min-width:800px" href="highres.jpg" />

The img tag remains unchanged. The link tag can be placed immediately before the img tag, or elsewhere, all in one place – separation of concerns. Plus, it can apply to elements other than img, while causing no trouble in older browsers but being easily polyfill-able. ‘selector’ is the only new attribute.

Maybe somehow syntax can be created to modify urls, such as changing those that match “[src^=/lowres/]” into the /highres/ directory. That way you don’t need large amounts of media queries.

Maybe not even <link> is the best solution. A new element to change any attribute based on media queries? Or am I getting too out-there…

<adapt select="[src]" media="min-width:800px" attr="src" replace="/lowres/" with="/highres/" />

Many, many use cases. Many, many abuse cases. I’m just thinking this all up as I type.

Server-side solutions sound useful for some, but not all.

Niels Matthijs says

Instead it’s more like a media query,

But if it is doing Media Queries’ job, it should look more like Media Queries.

Am I the only one that finds it weird that with quotes likes these nobody seems to be considering actually making it a part of media queries (and css), or at least pulling all this stuff away from html where it clearly doesn’t belong?

Are there any good arguments why this needs to be added to the html spec?

Petra Gregorová says

My main concern with adopting srcset isn’t just its fugly syntax but (just like Jeremy mentioned) most importantly having risk of losing the ability sticking to mobile-first approach, which I am very much fond of and would hate for us to have to get away from.

musictheorysean says

I’m a n00b to writing things with web languages and have just started looking into how to design scaled layouts. After reading a few articles about this today: I hands down want to be writing picture and not srcset. It’s much more intuitive, as HTML 5 should be.

Mat “Wilto” Marquis says

Not too late to change my vote to <yayBruce>, is it?

Excellent sum-up, sir.

Mat “Wilto” Marquis says

…it has been a long week.

Andy Davies says

Both and srcset suffer from the problem of embedding viewport information in the element/attribute.

There’s something very interesting and elegant about @necolas’s idea for responsive images…

The image and alternatives are specified in the image tag, and the information on which image to use specified elsewhere.

Not sure the syntax or using media queries is right, but the separation is…

Justin Avery says

Great overview there Bruce.

Agreed that it isn’t finished and needs some refinements, especially with regards to the w or h referring to min or max width. Perhaps there’ll be an addition and have nw nh, xw xh to provide some options (although I’m sure this will piss remy off even further).

Consider it added to this weeks Responsive Design Weekly

Nicolas Froidure says

I think it’s a bad way to have responsive images. Why not simply use queryParams, something like image.png?viewport=800×600&dpi=75 ?

Or maybe http request headers like x-viewport=800×600, w-dpi=75 ?

It has the advantage to run out of the box, old websites could be ok with it by simply switching to a newer webserver who understand those parameters.

Nicolas Froidure says

Or uri templating like : image.png?viewport={window.scrollWidth}×{window.scrollHeight}&dpi={window.dpi} ?

Larry Garfield says

There’s a ton of interesting observations in this post. :-) Nice work, Bruce. I want to break it out into 3:

1) The dev/communication process for HTML5 in the regard is quite broken. It needs fixing. That has nothing to do with the particulars of image handling.

2) There’s the general syntactic approach of multiple verbose tags vs. terse complex attributes. For me, the verbose tags wins hands down because it’s discoverable. Reading it, I can figure out what it’s supposed to do. Reading this thread, I honestly don’t know what the various values tucked into the srcset attribute even do and it sounds like no on else does either. That to me makes a more verbose and self-documenting syntax (picture or otherwise) mandatory.

3) Basic approach. This is an important point I hadn’t considered before myself, but I think it’s a crucial key question:

Should the general approach to responsive images be author/server controlled or client/browser controlled?

In the first case, the markup should provide detailed information about when each variant should be used. Media queries are the obvious tool here. Yes, media queries currently can’t handle things like pixel density, bandwidth, etc. That problem is not unique to images, though, and should be solved generally for media queries either way. The client logic is then very simple: iterate through the listed variants until the media query for one of them matches, then use that.

In the second case, the markup should provide detailed information about the image resource itself, and that’s it. Vis, it should specify not how big the image should be displayed as, but the resolution of the image itself, the format, the dpi, vector or raster, etc. (Remember, SVG can scale infinitely, by design.) In essence, we’re providing the header of the image file serialized into HTML. The client logic is then much more complex: it has to figure out based on that information what the most appropriate variant to use is, for some definition of appropriate. Defining “appropriate” is out of the scope of this comment. :-)

One thing to note is that I said dpi, not “2x” or “6x”. “This is a double-sized image” is a concept that applies only to iOS devices, because they’re built that way. That’s not surprising given that srcset came out of Apple, but for the majority of network-connected devices that are not iOS devices it is a totally meaningless distinction. If we’re going to do it, do it right and provide no-assumption information about the image. Let the client then figure it out.

There’s a very good argument to be made for the second approach, mind you. As Bruce notes, the client can then implement logic for black-hole-bias rather than forcing authors to. There are cases now where a phone is being used as a data access point but displaying a graphic on a 50″ TV, so wants the biggest image possible; that’s data that the client should be responsible for knowing, not the server. It would also be easier on designers working in a dynamic authoring environment like a CMS, because the CMS can just collect all of the variants it could generate, dump the information of all of them into the markup, and let the browser deal with it. That information would all be determinate, and not have to be input by the user. It would “just work”. (And if the CMS generates derivative images on the fly, that’s fine. It can just list the parameters of the derivative that it would create, and then if the browser asks for it it will generate that resolution/dpi image on the fly. Score!)

However, there’s also a strong argument to be made for the media queries approach. The strongest argument there is that the resources may not be completely interchangeable. I may want to use a full-size picture of a person when there’s room, but at smaller screen sizes only show a headshot. (To all the responsive fanatics who insist that the same content should be shown to all users: That would still be doing that. Deal.) That’s not a distinction that the client can know if all its given is metadata about each variant.

We also would want to make sure that whatever we do we make it consistent with audio and video tags. Everything we say about size and bandwidth and format for images applies there, too. Knowing not just format but bitrate, resolution, etc. of a video would be very helpful for a client, so that it knows to not download a video larger than its screen resolution. It could also trade-off between bitrate, resolution, bandwidth, and “what formats does this device support” much better than I as a server-side developer can. As a server-side developer, I just provide the client with all the data it needs to do what it knows is best.

Given that, I am somewhat leaning toward the “metadata” approach, and let the client sort it out, largely because I’m a CMS author and it would make my life simpler. :-) I’m still overall undecided, however.


Larry Garfield says

Nicolas: query parameters won’t work. Query parameters are function arguments to an executable function on the server-side. That works if and only if there’s a program waiting on the other end of that URI. In the case of a media resource that is not something we can assume, so query parameters are a no-go. That data needs to be encoded elsewhere.

Nicolas Froidure says

@Larry this convinced me :
> You may want to use a full-size picture of a person when there’s room, but at smaller screen sizes only show a headshot.

That something a web server can’t do easily.

Bruce Lawson says

Larry, Nicolas – that’s what I mean by “art direction” in the link in the article.

Constantinos Tsarouhas says

I like the <picture> suggestion a lot more, but I would make one little modification:

<picture alt="angry pirate">
<source src="hires.png" height="960px" width="320px" />
<source src="midres.png" height="480px" width="160px" />
<source src="lores.png" height="240px" width="80px" />
<!-- fallback for browsers without support -->
<img src="midres.png" height="480px" width="160px" alt="angry pirate" />

Note that I added the source’s size as an attribute, in a similar fashion that the <img> element has, instead of the screen’s size. The browser can still choose between a source and even change the source while the page is scaled, because it knows the pixel size.

Michael Salmon says

When I saw the two suggestions my first thought was that a new programming language was being suggested and that didn’t make sense to me when we have a perfectly good programming language in the browsers that support html5.

My suggestion is to use an event handler to set the img src before it is loaded. I have tried to think of a good name but the best I could think of was onView although I liked onZoom as well:

Where xyzSet is a variable containing the data that srcSelect needs. I think that srcSelect could be a standard function that takes a list of entries with image url, min width, min height, resolution factor and net type which could then be used to select the image src. There could even be a standard variable that uses the image id as an index.

I included net type so that mobile browsers using edge could select a lighter image than those with WiFi, something like 2 is edge, 3 is 3G, 4 is 4G then skip up to 101 for 802.11b, 102 for 802.11g etc.

I know that requiring javascript isn’t quite PC but on the other hand the canvas tag isn’t all that useful without javascript. Using javascript means that the selection criteria doesn’t have to be decided today and I think that that is important.

Mark Greenwood says

I’m a bit late to this party but thought I would chime in a little with my humble opinion.

The thing that bothers me most about the direction these tags are taking is the amount of repetition and the sheer verbosity of the code, this can only lead to evil. It increases the chance of error and, to be honest, it’s a pain in the arse.

Personally, if I had to choose one, right now it would be the picture element. I’d hate using the srcset attribute within img, it just doesn’t make sense and it feels like a hack.

However, I’d much prefer a different direction. My thought would be a refactoring/adaptation of the <base> tag…

<base href="/img/min800" media="screen and (min-width:800px)" rel="img" />

It’s not a million miles from what the tag was originally intended (“specifies the base URL/target for all relative URLs in a document”… from w3schools, don’t hurt me) and could potentially be used for video or whatever else via the rel attribute. It would also cut down on repetition.

Obviously, assets would have to be managed properly for it to be successful but I think it would be much cleaner in the source and almost make some sense.

Nicolas Froidure says

@Mark : It seems more smart. It’s a great idea.

Mark Greenwood says

@Nicolas: Thank you sir, the only problem, which I remembered afterward is that you can only use one base tag per page, so that example may be no good and an alternative tag would likely be needed.

Just throwing it out there. I’m keen on the core idea of a tag that sits in the head, directing the browser over verbosity, though.

Brian Koser says

Well, if those of us that prefer <picture> are to take our cues from “The Great Vendor Prefix Hullaballoo of April 2012,” then we should ignore srcset and continue using <picture> polyfills until the Working Group gives in.

madcampos says

i think that leaving the browser to decide e few things is a good option, but i want to be able to decide stuff my way.
the syntax of srcset i just too weird, it’s idea (of leaving things to the browser) cen fit greatly with the picture element in my opinion.

pelicanorojo says

When aspect ratio may be considered constant, it will be nice that given one image like jpg format, the browser only download the frequency components that it can renderize for a given image size. I mean instead of low pass filtering when the image have more frequency information than needed, only download the low frequency components you may call it “smart image download”.

It will be great if also the server can continue the image download from a given point, in order to download higher frequency information when needed (for example in a resize). @pelicanorojo

Rob says

For actually working day to day with any syntax it’s vital that:

a) The syntax is easy to understand
b) Syntax can easily be integrated into various templating systems
c) Syntax can easily be integrated into Content Systems

The only one that appears workable is the PICTURE tag, though “picture” isn’t the right word – “image” or “imageset” would be far more understandable.

As far as the code goes, using media-query style values is OK but surely it would be a lot simpler to use the browsers viewport [width] to determine which image is displayed?

I propose a “viewport” attribute, with the value being the minimum viewport size, eg in this example hires.png would only display if the viewport was at least 800px:

<picture alt="angry pirate">
<source src=hires.png viewport="800">
<source src=midres.png viewport="480">
<source src=lores.png>

<img src=midres.png alt="angry pirate">

To me, as someone who develops web site for a living, this makes far more sense.

Aaron T. Grogg says


that is all.


Chris Pratt says

I think the chief problem with srcset is that it inherits the problems most CSS properties have: they’re too freeform, which leads to confusion about what goes where and in what order.

In principle, though, I do like the idea, but I wonder if it couldn’t simply be handled like data- attributes in HTML5. Essentially something along the lines of:

<img src="foo-lores.jpg"
alt="decent alt text for foo.">

Now, I’m not sure what havoc a decimal point in an attribute name might cause, but honestly, I don’t think you’ll see many if any scenarios where you need a fractional resolution component. Still, it reads much easier to me, at least, and the precedent for this pattern does already exist because of `data-` so it shouldn’t be overly difficult to implement by the browser vendors.

MarkC says

Isn’t it about time we had an “empty” image elements whose src can be set via CSS? Bonus points for making it easy to slice subsections from the image. I propose <icon /> and <decoration /> for the elements. Something like this:

<icon id=’img1′ />


#img1 {
src: my_image.png;
image-slice: 0 0 48px 32px;
/* Top left coords, width and height of icon */

#img1:hover {
src: my_image.png;
image-slice: 0 48px 48px 32px;

Yes, this can be done already using a div or other element with a background-image, but for the sake of semantics I’d like to clearly have my icons described as icons, and my non-content images described as decoration.

By doing this in CSS we also get to use media queries that exist and work already.

I’d also extend the existing <img /> element so that its src can be overridden by CSS in the same way.

SelenIT says

The CSS way of making images responsive (as mentioned by MarkC above) already works in WebKit-based browsers and Opera (with ‘content’ property, see for example). May be such a sort of progressive enhancement of the image for hi-res screens, with default low-res source as a fallback, is a not so bad idea?

And what about reusing not video pattern, but another pattern, that has been used to link things to img element for ages — the pattern of map element? Why not to introduce the separate srcset element and link an image to it with usesrcset attribute? The conforming user agent would wait for the srcset to load and then choose the most appropriate source for the image, while others would just ignore both attribute and element and just show the plain old img. Would this solution better than srcset attribute from usability point of view and better than picture element for backwards compatibility? The similar pattern is already used in HTML5, too — for datalist element, for example.

bruce says


the problem with using the CSS content property is that all browsers have an algorithm called prefetch in which they begin downloading images as soon as they are parsed in the HTML – before they even start to process JavaScript or CSS. This is done to make images appear faster (as they’re the heaviest elements on a page).

So by the time the CSS is parsed, the image is already partially downloaded, and is then subsequently swapped out. Opera Dragonfly/ Firebug/ Web Inspector shows this.

Kumar says

Imaging and audio are the two which is given more importance on HTML5 I believe, since I have started reading about HTML5 I have been reading more on images and audio, which is quite good thing, as I believe earlier versions lacked this.

Kzqai says

This is why svg needs to be everywhere! That at least eliminates non-raster-requiring images, or at least it would if vector images weren’t so much more difficult to make.

Baumr says

Any updates since May?

mark erickson says

I’m just starting to wade into the swamp that is “imaging for mobile”, but on first look it seems this is largely a back end issue. I can’t see changing html markup syntax–and thereby affecting millions (billions?) of existing sites.

Instead, let’s program the server to deliver a “sanely” sized/resolutioned image to the device.

To do this the server would like to get 4 pieces of information (relatively accurately!):
1. Device display size
2. Device resolution
3. Current browser zoom ratio
4. Current download speed

Device size and resolution can likely be found by examining an RDF profile or a WURFL lookup. Fallback would be user-agent sniffing.

Current zoom ratio is tedious to compute across browsers, but Yonran’s Git: detect-zoom shows promise.

Current download speed is difficult! The best way is to measure it is by downloading an image and calculating the download speed. By the time we get the results calculated, the browser is probably prefetching the other images—no good! So, probably the best we can do currently is to go ahead and measure the download speed on the first page the user requests on our website and then use that measurement on the next page the user requests. As long as we are suggesting large changes like image and picture tags , let’s mandate that the current download speed be made available as a cookie in the initial http request. Possible sources for calculating the speed would be the device itself, speed sampling by the browser or even speed sampling built into javascript/jquery.

If we can’t get the info we need to send a sane image from the server, here are some fallbacks:
1. For pre-html5 browsers, assume the worst and just send all low-size, low-resolution images.
2. For html5 browsers we could stay within the current html specs and add some “data-“ attributes to our image tags. For “must see” images: . For less important images that could even be excluded on smaller mobile screens:

One final, radical thought! LET’S NOT DOWNLOAD ANY IMAGES AT ALL until the page has fully loaded. Once the page has loaded and #1-4 above are known, then let’s efficiently lazy-fetch all server-optimized images. We could put the src in .

mark erickson says

Oops, my image tags were removed in my post above.
* “must see” images have data-show=”required-large”
* “excludable” images have data-show=”excludable”
* lazy-load src are in data-src=”myImage.png”

Joseph says

The one thing that makes me want to pull my clothes off and run around screaming “illibilly-illibilly” on the mo0r, is the unpardonable fact that we need to provide different sized images for every conceivable density.
Besides, whether we use ‘picture’ or ‘srcset’ it still does not solve the problem of background images.
I would much rather have a server-side solution that simply generates (once, when it is first requested) and serves the best resolution for the job.

Joseph says

Sorry, forgot to add: Would it be such a difficult thing to do or be a big security risk if UAs would expose the device’s pixel-density to the server?

Fernando Jr says


Your comment was what helped me most in my research. So that the browser does not download the image twice, as Bruce said, I started without the attribute img src parameter to the property and as a media query I wrote the source parameter, downloading the image only once. Possessed 03 images in the img folder.


Following HTML:



Following CSS:

@media screen and (max-width: 599px) {

#imgResponsive {
content: url(img/small.jpg);


@media screen and (min-width: 600px) and (max-width: 991px) {

#imgResponsive {
content: url(img/middle.jpg);


@media screen and (min-width: 992px) {

#imgResponsive {
content: url(img/big.jpg);



I am Brazilian and I follow the discussions here on the site, are all to be congratulated.


Fernando Jr.

Dario D. Müller says

Hey guys,
I have build a image-rendering software called “Customize-Images”. It can render custom image-sizes for Responsive Webdesign. With just a change of the imagename, the script creates a thumbnail-size, medium-size, portrait- or landscape-view of a choosen image. I’m happy if someone would give some feedback.
It’s hosted on GitHub:

Som says

I assume this discussion has been well and truly superseded (a year and forever on), but as I’ve come across it I feel I should weigh in.

I invariably run into this issue on a site-ly basis. What is currently the ideal solution for varying screen densities and resolutions?

I’ve tried various server-side, JS, and CSS trickery, and you could argue until the cows come home about the efficacy of each.

Ultimately, the simplest and most effective solution I have come across (and the one I use today) is a single, specially prepared source image inside an tag with a defined @height and @width.

Increasing the size of an image 100% (using nearest neighbour) and saving out an optimised JPG at 20% quality yields surprisingly good results on retina screens.

The tag is identical, ie. so semantically everything is good. The only obvious drawback is that the content isn’t necessarily “as-specified”, meaning it will show up in image searches, etc. looking pretty weird. Of course there’s another million solutions for this, but a natural resolution attribute would probably suffice.

Here’s a fiddle:

Alejandro Teixeira Muñoz says

Hi all;

My problem with resizing images is very big. I´m developing a museums network, that involves the presentation of online media to the final user. My idea, refering to the imageset, i think is much easier.

Why not user a different kind of attributes??

and the the broser will just choose between the files with names:


Standar Density

Double Density:

The only think is just choose one of ( “vieport” or “container”) and add the density option. This combination will guive all the options.
Also, is very easy to configure our backservers to produce this names on pìctures. And .. maybe.. why not make src of <img dinamyc….

for example…

This is also another idea.. but it´s not standar HTML at ALL :P


**PD I´ll post soon my system for rendering images adapted to size of container without restrictions on size, and with images presentation!! Hope it will help someone!

Join the discussion.

Some HTML is ok

You can use these tags:
<a href="" title="">
<abbr title="">
<blockquote cite="">
<del datetime="">
<q cite="">

You can also use <code>, and remember to use &lt; and &gt; for brackets.