Responsive Images and Web Standards at the Turning Point

by Mat Marquis

42 Reader Comments

Back to the Article
  1. One of the points Mat drove home in his article has to do with the priority of constituencies, a founding principle of HTML5.  I was going to leave a comment here, but I got carried away:

    “The Unbearable Lightness of HTML5”:

    Enjoy (and feel free to disagree).

    Copy & paste the code below to embed this comment.
  2. Definitely agree that content negotiation via network protocol between client and server is where this should be handled. Neither proposals address this neatly.

    Webp as a new format seems to be the perfect fit in terms of image container and it has small bandwidth-friendly compression/quality. It has very low adoption so far which means backwards compatibility shouldn’t be a problem.

    I quite like the idea of an OnBeforeLoad event but can see the behaviour being rolled into the UA which should know from the first http-response what to expect and what to request.

    Quick and dirty approaches could simply inline bitmap streams via <data>

    Copy & paste the code below to embed this comment.
  3. Whether it’s a new tag since the img won’t do; I do agree that the ‘responsiveness’ bit should be treated in the CSS. Serve the smallest by default and use media queries to server larger ones as fit.

    Copy & paste the code below to embed this comment.
  4. I think “tesmond”: nailed it. Ideally, the best responsive solution would be to have the UA do all the heavy lifting, not the author. Only download as much of an image as is needed to fit in the space it takes up, and as makes sense with the allocated bandwidth.

    If that’s not technically feasible, I would prefer “guile’s suggestion”: over both proposals. Why would you want to have media queries throughout the document on every image, when you could set it once in the head? That’s just extra bloat and extra work.

    Copy & paste the code below to embed this comment.
  5. Wow, such a great, great clear statement of the problem. For all those commenters who think they have an easy answers to responsive images with some kind of simple css, js or html-fu,  I want to point hardy souls to Matt Wilcox’s 50-minute exegesis of the problem and the massive list of failed solutions that have come and gone. Respect:

    I want to say that I wholeheartedly with Matt’s rant at the end of this video that there’s something wrong with both the “picture” tag and the “set” attribute, and the whole idea of putting what are essentially media queries in the img tag. Yes, it is easy to read, and yes it’s clear what it’s doing, but man it is brainlessly verbose. Worse, it mixes content and presentation in the most egregious way. It feels totally anti-standards. You’re dumping all your media queries into every single picture. Ugh. UGH! It’s nice that it’s low-level, but it’s just mindlessly low-level.  It’s maddening to manage, and probably also error-prone.

    And all-CSS solutions won’t work for the simple reason that they don’t stop browser pre-fetching. So let’s move on from that discussion please. The real problem is controlling bloat. We’re already testing for width in JS and CSS. Now we’re also going to do so in HTML? Someone please consolidate this madness.

    Matt’s near-genius idea is to put “breakpoint” definitions in the head:

    This is by far the best idea I’ve heard so far. Flexible. Clear. Editable. Backward-compatible. Bloat-free. I hope this get looked at very seriously. Can we get some high-profile browser reps to say “yeah, this is doable!”? This is a genuine turning-point moment in the history of markup, and it really needs to be done right.

    Copy & paste the code below to embed this comment.
  6. Gabrielso beat me to the punch on recommending the object element. This has been around for over a decade and supports fallback content.

    <object type=“image/webp” data=”[src_url].webp”>
      <object type=“image/javascript;responsive” data=”[src_url].jpeg”>

    That said, I believe we’re trying to solve the problem with the wrong pillar of the Web. This is an task for http content negotiation, not html.

    I believe the ideal mark-up is as follows
    <object type=“image” data=”[url_to_generic_entity]”>fall back html</object>

    The user agent will send accept headers regarding preferred image formats and resolutions. The Web server will return the best suited representation of that entity

    Copy & paste the code below to embed this comment.
  7. The option looks much better. I fully agree that we need consistency with the video and audio tags.

    Copy & paste the code below to embed this comment.
  8. We are just starting to use HTML5/CSS3 and jQuery exlusivly and finally don’t even care about IE8 and below. Why over complicate a feature that probably won’t be necessary in the near future. I’ll tell you why:
    1. The web is getting faster each day (did you try 4G?)
    2. Most smart CMS will reduce images on the fly using script.
    3. Did you try this: Jpeg Mini (

    I find it hard already to keep up with “standards”.

    Copy & paste the code below to embed this comment.
  9. All of this discussion of , image supplements, JavaScript, is redundant (for the current state of the art…).

    The solution is to use progressive images.  And the web can be progressively upgraded (put not intended), ie:
    – enable Keep-alive and pipelining on your server.
    – and put some extra smarts into the browser (eg: use range-requests for subsequent parts of the image).

    Copy & paste the code below to embed this comment.
  10. I think this solutions just bloat HTML documents beyond recognition. We should aim for low coupling here, and defining what specific content to serve for a gazillion devices on a document that should specify the way my content is structured doesn’t cut it.

    I’d much prefer a solution where browsers would reliably send their capabilities back to the server as HTTP headers. I’ve been using WURFL as a way to serve images properly depending on the reported User Agent; however, we know User Agent sniffing is pretty unreliable (and a bit inefficient).

    Having the client send additional headers such as device width, device height, supported formats, connection speed and other info would be a way better solution, IMHO.

    Copy & paste the code below to embed this comment.
  11. Perhaps I am being naive, but what would be so terrible about using PHP to dynamically generate the required image size?

    @media screen and (min-width: 300px) and (max-width: 500px) {
    .box1{background: #ccc url(‘get_dynimg.php?img=pic1&size=500’) top left;}

    designer can simply make images max size required & php will generate smaller as required.
    a simple few lines script can work for all & probably do it in chunks, so 500px img is fine for 300-500 screen, very little excess.

    I’m pretty sure this can be used to provide different pics depending on the screen (close up, wide angle etc) it doesn’t really require anything to be changed from normal practice other than a discrete server side script.

    Copy & paste the code below to embed this comment.
  12. Hi there, this is a great resource for the Responsive Design Knowledge Hub. Check it out here:

    Copy & paste the code below to embed this comment.