Skip to content

24 ways to impress your friends

Responsive Images: What We Thought We Needed

45 Comments

Comments are ordered by helpfulness, as indicated by you. Help us pick out the gems and discourage asshattery by voting on notable comments.

Got something to add? You can leave a comment below.

Mat Marquis

I don’t want to be that guy that swoops in and corrects things in blog posts—I really don’t—but there are a couple of shaky premises in here and I don’t want people left thinking this is a solved problem.

First, the two proposals aren’t competing. I want to put that out there right away—the two solutions, in combination, serve to address the list of use cases we’ve outlined at http://usecases.responsiveimages.org

In terms of a “responsive image format,” a great deal of discussion around this has already taken place in the RICG. The issue is that this—like image negotiation based on bandwidth, as you mention—is also 100% in the hands of the browsers. However, there are a couple of additional catches: first, the development of this alternate format has to be funded by the vendor(s) and they have to do so while 100% willing to share this format with all other vendors, even if they’ve chosen not to pitch in. The developing vendor(s) would be left footing the bill. As you can guess, the browser reps we’ve spoken with don’t really consider this to be an option.

The other issue is that there wouldn’t be any predictable fallback. JPEG2000 has still seen little-to-no adoption and can’t reliably be used today, but when chucked into an `img` tag it will still be requested by the browser. Then we’re left with the issue of providing a fallback, after that wasted initial request—we can’t exactly feature-detect for an image format. We’d have the option of doing content negotiation on the server-side, based on UA detection, but that’s about all. It should be noted that a part of the `picture` proposal is that each `source` would accept a `type` attribute, allowing UAs to skip over sources of unrecognized types, for this exact reason.

We regards to art direction not belonging in markup: it’s a markup issue as much as the size and cropping of any content images are—otherwise we’d be using the same size images for everything and managing it with CSS. Don’t get hung up on the “art direction” name; this isn’t stylistic so much as a matter of ensuring that the content being delivered is appropriate to the user’s context.

Implementation-wise, too, it wouldn’t be a matter of adding a quick cropping feature in CSS—not on a production-scale site, unless you knew the primary subject matter would always be in a certain part of the image. At best, you could hope to create a custom CSS framework where you’re relying on scaling and `overflow: hidden` to focus on (still pre-determined) parts of the image. You’d end up with an inflexible art direction system that still forces users to download a larger image than they’ll potentially need.

I agree that responsive images aren’t much of an issue in the multi-column wireframes you’ve posted, but those designs may not be a good fit for what’s being proposed—the idea is not that you’d be required to use this in every case where images are being resized, but rather in the case of large “hero” images—the Boston Globe’s Magazine page was what started us down this path, and still serves as a great example. Further, the size of the containing element isn’t an unknown, and we don’t need the image to be aware of it any more that other parts of our layout have to be inherently aware of their containing element’s size. It’s up to the designer/developer to choose image sources that are appropriate to that part of the layout.

Re: not living with the problem long enough—I assure you, many of us have. This has, with no exaggeration, been my unpaid part-time job for the better part of a year now. Of course there are flaws with the proposed standardize solutions to this issue, but many much, much smarter people than I have been working on solving this for a very long time now. If it were a matter of just having a “eureka” moment, I doubt we’d be where we are now. In the meantime—my full-time job—I’ve been using Picturefill (which mimics the proposed markup pattern) on day-to-day client work. I’ve had great luck with it so far.

I want this to be done and solved more than anyone; I do. I’m doing the best I can, and the other members of the RICG are working just as hard on this—and harder, in many cases. But this isn’t solved, and nebulous statements like “we just need a new image format” or “let’s just come up with something better” don’t get us any closer to a solution. If a better solution were to come along, that would be the end of it. If anyone reading this should have one, I welcome it like you would not believe.

Not doing anything about this problem, however, is not something I consider an option. It smacks of perfect solution fallacy, and passing on an option because it isn’t perfect means failing our users for the sake of theoretical purity. I’m not willing to do that; nobody should be.

I urge anyone who finds themselves interested in this subject take the time to familiarize themselves with the work being done by the Responsive Images Community Group, and read through the prior discussion at http://lists.w3.org/Archives/Public/public-respimg/, http://www.w3.org/community/respimg/, and http://lists.w3.org/Archives/Public/public-html/

Join us, and help us solve this.

David Bushell

From all I see shared and developed on this subject I keep asking myself, just how important is a solution?

With all the responsive sites I’ve buit the majority of images tend to be scaled down from 100% to around 40-60% of the original dimensions. Perhaps more for full width hero banners.

If we’re happy with the bandwidth consumption shipping those images at their largest size for the largest viewport, why is it such an issue shipping them for smaller screens? Sure, some unnecessary bytes, but screen size has very little relation to the client’s available bandwidth.

I’m not saying it wouldn’t be nice to serve the perfectly optimised image, but I have yet to see an implementation that can get this right.

And as alluring as the idea of responsive images are, we’re evidentially willing to throw logic and bandwidth concerns out the window when it comes to shipping @2x “Retina” images for high-dpi screens on sexy devices.

My point is we’re not in dire need of urgent change. Find a design style that is suitable for the Web and not overly reliant on raster graphics. Yes, we need to continue developing this idea of responsive images. But if it’s not ready yet, the Web isn’t going to explode. Design decisions are always going to play a bigger role.

Jason Grigsby

@junior wrote:

One of the unfortunate realities of browser “solutions” is that the community at large only gets to decide after they are implemented, whether as experimental, browser prefixed or fully implemented.

That’s one of the beautiful and amazing things happening with responsive images right now. The majority of the work and development is happening by web developers, not by browser makers.

Community Groups were created by the W3C to give web developers and designers a voice in the standards process. The Responsive Images Community Group is the best example of that process in action.

Join the group. See something that doesn’t make sense? Submit a bug on the RICG Github project or send a pull request.

I highly encourage people who are interested in these issues to look at the use cases that the RICG has defined.

Most discussions about responsive images that don’t reference use cases end up with people talking past each other. The best thing you can do to have a productive conversation about possible solutions is to familiarize yourself with the use cases that the proposed solutions are trying to solve.

Finally, I hope everyone takes it to heart that you can contribute to the responsive images solution. Join the Responsive Images Community Group. You really do have a say in what gets implemented.

bruce lawson

Echoing what others said. picture and srcset aren’t beautiful (neither is much of HTML or the web stack). And verbosity is a problem.

A new image format will take ages. And content negotiation doesn’t work where there is no server (in an increasing number of environments such as epub, or an HTML front end to assets in kiosk etc).

I had sympathy with the idea that art direction is a CSS matter. But debating that is fruitless anyway; by the time the browser has the CSS, it’s already started to download the image that has an src in the markup.

The only way round this now is to use an empty div in the markup and use media queries to drag in a different background image using WebKit’s img-set http://blog.cloudfour.com/safari-6-and-chrome-21-add-image-set-to-support-retina-images/. That would lead to lots of content images being removed from content, added to the CSS layer so that they are visually there but have no alt text.

Matt Wilcox

+1 for Mat and Grigs.

This is actually a good article, and all of the points are valid. The problem is they’re all old points that have been looked at in great detail already.

What the article misses – and it’s very easy to miss if you don’t read almost everything that’s been written on the topic – is why we have ended up with the two solutions we have. It’s not for lack of trying other options, including all of the very options that are mentioned, among others. It’s because the other options are even less viable or plain impossible (sizing images to their context is impossible, but we all agree that’s a far better approach).

I’m actually inclined to agree that both syntaxes are too verbose for general use. Even so, they have their places and they really are the best solutions we can realistically come up with.

I, for one, would love better ones. We’ve been looking for better ones. We haven’t found them.

As an aside: the entire issue would be fixed easilly using current tech if we had the ability to tell browsers to not pre-fetch images. i.e., behave as browsers used to. It’s actually the browser’s “performance enhancement” which is the problem here.

Jason “My Little Pony” Grigsby

It’s funny how this article feels like it jumps into the middle of a conversation from two directions.

From one direction, it seems like it jumps into the middle of the responsive images conversation without context. On the other, it has become clear to me that it is a piece of broader thinking that Paul articulated in his A List Apart article and his follow up blog post

I think you need to read Paul’s ALA article and follow up post to really understand what Paul is getting at here. They are interesting food for thought. I find the general concepts in the Web Aesthetic appealing.

At the risk of picking nits, I wanted to make a couple of points on a few of the details in the article.

Under #2, the use case for art direction isn’t solely cropping of images. The Meego Browser example in the use cases document shows a video of how an image changes entirely as the page reflows.

For #3, I concur. I wrote a bit about this problem when looking at what would happen if we actually had a new image format. Like most of these issues, it comes down to a battle between the lookahead pre-parser and web developer convenience. Browser makers argue that the lookahead pre-parser is an essential user feature (making things faster). And users > web developers > browser makers.

Regarding #4, this is in fact what the RICG is doing a lot of. Prototyping work. Defining use cases. Seeing what works and what doesn’t. Creating polyfills. Testing them.

The way I look at it is the best thing we can do to make sure a solution is found is to keep pressing forward with solutions that people can test, use, improve or bitch about.

If we’re really lucky, what we’re doing will cause someone to say, “OMG, why are they doing it that why? This would be much better. I’m going to go code it up to show them.”

That would be awesome! By continuing to push the standards process, we keep the fires stoked and increase the likelihood that we find a solution.

Peter Macinkovic

I think this article is an important discussion piece, in particular the subheading of “We haven’t lived with the problem long enough”.

This brings up an interesting philosophical challenge: Should we implement a top-down approach of standardized markup to tackle many of these use-cases or rely on a bottom-up method in which the cream rises to the top and a solution becomes naturally apparent within existing mechanisms?

I bring this right/left dichotomy up for this article because what I found more interesting in both the article itself and in the comments section was just how influential the Boston Globe website is in setting the need to replicate functionality on other products.

John Mellor wrote recently in a W3C email chain about responsive images and even mentioned this article[1] about the srcN spec replacing srcset and < picture > specs that outlined specific uses cases and how they would be solved within a well thought out spec.

However the reality is we are such a replicate and iterate culture: for every problem we resolve or standardize another two will emerge by a influential subculture that pushes the limits of design and content access for the web.

Seeing the web change so much over the years, I could remember how influential the 960 grid was as a way to bridge the gap from traditional print design to web design layout. All over, websites with sliced up images were popping up with little consideration for resources management or bandwidth consideration. This was due to a labour divide of traditional print designers entering a new market in which they were not trained in the field of computer science.

Clients lapped it up. They bought the sizzle instead fo the steak and similarly themed websites grew exponentially before some really savvy people realized that these designs kind of sucked.

The came the rise of fluid and responsive websites; technology that has existed for years prior to it becoming mainstream.

This is why I find your final line quite poignant:

“…let’s embrace the constraints of the medium, and seek out new solutions that can work within them.”

Humans are way more creative when working with restraints. It allows us to tackle problems in different and progressive ways. However creating new standards, even ones we will regret in 3-5 years could further open up this realm of creative restraint.

I can envision a scenario in which some 9-year old HTML savant is watching Minority Report or Public Enemy and looking at the UI created by Motion Designers for film and saying “ I wonder if I could build that?”

If they do, people will be amazed, replicate it and point out problems with it until it continues to iteratively get better.

And it will be awesome.

[1] http://lists.w3.org/Archives/Public/public-respimg/2013Sep/0087.html

Scott Jehl

Hey Paul,

It’s good to see this issue continually discussed in visible places, so I’m not opposed to seeing these points raised again here. That said, I do agree with others that most of these points have been discussed heavily in public over the past year and a half, and I do think that the RICG and broader community has given them all adequate attention and respect.

I can’t offer much more feedback than others have in this thread, but I would like to point out that there is another approach we’ve been tinkering with that hasn’t been mentioned here: Compressive Images. The approach doesn’t satisfy every use case the picture proposal aims to address, and I think it may even complement other techniques well. But if simplicity and performance are your main goals, this approach might just meet your needs. We covered the technique over on Filament Group’s blog, and you may have seen Jeremy Keith’s post about it as well. Either way, here’s the link. http://filamentgroup.com/lab/rwd_img_compression/

Thanks
Scott

Yoav Weiss

To add on Mat’s comment, even if a responsive image format was agreed upon tomorrow between all major browser vendors (with all the IP & political issues miraculously vanishing), we still don’t have any mechanisms that would enable browsers to efficiently fetch such an image format, without having a negative impact on performance in one way or the other. I wrote a little about that at: http://blog.yoav.ws/2012/08/Fetching-responsive-image-format

I don’t think we should give up on a responsive image format, but even in the best case scenario, it’s a long while (IMO 5-10 years) before such a format will be something Web developers can actually use.

I doubt waiting that long is the best course of action.

Pete B

While simple images and iconography can use scalable vector formats like SVG

Exactly, and this accounts for a lot more images on an average page than people seem to give it credit for.

At this moment SVG has excellent support (even in IE) and hardly anyone is using it. Why?

Instead we seem to have got tied up in knots trying to invent a scalable bitmap.

Daniel

Great article. I completely agree that there has to be a better solution than creating multiple images, and it would benefit all of us if we worked toward new solutions, but I personally believe that using any of these solutions is better than the alternative. Which is not using anything and having a site that performs poorly.

Dave

Drew: not at all, I’m a web developer, geek and user of responsive design – this article seems perfectly pitched at me.

My point is that this topic has been covered extensively (both on 24ways in previous years and on the internet as a whole) and the time for thinking should probably give way to the time for doing.

Picture and srcset are two examples of people innovating to solve a problem, not only talking about it. They aren’t ideal but they’re far more pragmatic.

Paul Lloyd

Thanks all for reading my article, and for your contributions here.

I’m concerned that many saw reference to image formats and quickly read this as another unthinking critique, and not fully considered the later points I made.

In fact, think of these as being ordered in terms of importance, least important first!

I’ve posted some follow-up thoughts over on my blog. Hopefully this will provide greater clarification, or at least explain my perspective on this topic:

A Field of Ponies

(You can blame Jason Grigs for inspiring this title and poor equine related analogy!)

Paul

prisca

Hi,

just wanted to chip in to say that I really enjoyed this article, as well as the others on this topic on this site. I don’t understand why it is a bad thing to discuss this topic again. And Paul’s writing (and speaking) is always a joy as well as educational.

There are those of us who don’t have the luxury of time to read all there is to read on certain topics (even though we’d like to) – and, as far as I’m concerned, 24ways never fails to deliver quality content which I look forward every year.

Thank you, Drew and Paul :-)

Alex Morris

@matt – nailed it.

“As an aside: the entire issue would be fixed easilly using current tech if we had the ability to tell browsers to not pre-fetch images. i.e., behave as browsers used to. It’s actually the browser’s “performance enhancement” which is the problem here.”

This is a browser problem, if we want to get this done right – not stick a thumb in the leak, the vendors have to rethink prefetching/rendering and/or give us better means to influence that. A CSS load:none property might be nice for example.

The work being done by @wilto and co is awesome – I don’t think this detracts from that, but hoping for a cleaner solution isn’t a bad thing.

Charlie

I guess that the debate is symptomatic for vendor-led extensions that get adopted by (lazy) developers quickly and forced on the rest of the world as a de facto standard. More responsible developers then have to spend years ironing out the kinks or outright errors and adding workarounds to maintain compatibility for the millions of sites that will never get updated.

Like the viewport tag, it’s quite clear to me that markup is entirely the wrong place for this aspect of content negotiation which is essentially one of infrastructure.

First of all we should take a deep breath and realise that this is only a temporary problem. Very high pixel density screens are becoming the norm on mobile phones and tablets due to the commodification of the technology. As these are precisely the devices that are driving the debate, in a couple of years at most there won’t be a need to differentiate between high-resolution and ultra-high-resolution mobile devices.

The browser should be able to request the appropriate image depending on context. The best solution for this would be via an http-header similar to “accept-gzip”, say “accept-hires” would work filters in the http-server such as mod_pagespeed, which is in fact already doing much of the necessary work with the added goody of transcoding to Webp for browsers that support it (higher quality, lower bandwith = win win). Negotiation at the server level also allows for bandwidth to be considered – the browser can simply turn off the header if appropriate.

Designers and web developers would be able to ignore the problem by simply supplying a single file at the largest size. Deployment at the server level becomes even easier as more and more sites move onto content delivery networks that offer mod_pagespeed or similar.

A container format, similar to the icon format, could be the icing on the cake, but with all the problems of introducing a new image format entails: not only do browsers and servers have to be updated but image editing software as well.

I do like the <picture> tag because it is orthogonal to the <video> tag and supports cropping via media queries in CSS.

Junior

Great dissection of the issue. One of the unfortunate realities of browser “solutions” is that the community at large only gets to decide after they are implemented, whether as experimental, browser prefixed or fully implemented. Compare this to say, JavaScript libraries—jQuery, for example, rose in popularity from community usage and feedback (I know that comes with other drawbacks).

The problem I see with “living with it long enough” is it can result in myriad workarounds and hacks, or worse, even more proposals. “Living with it long enough” often means we could do better with hindsight, but at the pace things change do we ever really get there?

I also applaud your suggestion we start questioning how many images we really need. From a user experience perspective how often do we consider that for the information seeker images can create clutter and take up precious space? Why not offer links to images contextually? Users who click to see them indicate a desired action and others are none the worse. Another option could be offering more images on a page through user action, the way some sites offer larger font sizes or translations.

Ryan van der Wal

Great article! Taking the whole responsive discussion off the normal direction Wonder where this train of thought will lead us in the near future.

One word of criticism though. I don’t fully agree with that statement that ‘art direction’ doesn’t belong in markup. Partly right but there are numerous occasions when an image supports the content in telling the story it needs to tell. Those pictures should convey the right tone of voice at every device width even if that leads to having serve different pictures.

Wonder how Einsteins theory of: Problems are never solved in the field they are discoverd, will pan out for responsive design ;)

Claus Bermann

Interesting article and discussion to follow as a guy working in online marketing. Six months since the article was posted, what is the status on responsive web design for june 2013? As I am a non-programmer, what would be your advice in terms of responsive design-demands to a web agency pitching for a new web project?

Eric Portis

While it’s easy to get distracted about the size and quality of an image, and how we might choose to serve it, often the simplest solution is not to include it at all.

My point is we’re not in dire need of urgent change. Find a design style that is suitable for the Web and not overly reliant on raster graphics.

This kind of talk gets my goat. I know the web is a primarily text-based medium; has been, likely always will be. It’s hyperTEXT after all. But when I read these “web aesthetic” discussions I feel the need to fight for rich media—video, audio, images—as a first class citizen on the web. I dream someday such things will be as easy to describe, serve, and consume on a wide array of devices as a page full of paragraphs is today.

You can’t tell the story of the web without Flickr, YouTube, MP3s, image maps, gifs, 4chan, or Les Horribles Cernettes.

Efficient, universal delivery of rich media is a very hard problem with all kinds of dimensions—technical, legal, social—and we’re a long way from that dream, but don’t suggest we fix our broken arm by cutting it off.

Eric Portis

@David Bushell

The bigger “fix” is avoiding design that requires overlay indulgent decorative styles.

Indulgent, wasteful design is a huge problem! But it’s not the one I’m looking to a responsive image solution to fix.

As someone who publishes more images than words, I bristle whenever the implicit assumption is made that all images are presentational and all text is content (this assumption runs deep, as deep as the alt=”“ attribute).

The minimal, flat, content-first, content-out, typographically thoughtful and gorgeously legible aesthetic that’s emerged over the last few years has been a revelation and a delight. Ruthlessly purging decoration and promoting content is what we’re all after. The content I’m dealing with simply happens to be photographs, drawings, prints and stop motion animations. I want to be able to serve these in an efficient, scalable, standard, simple way, and right now, I’m using awful <noscript> hacks, four versions of every image, a pile of <video> MQs/sources, and hopefully googling for “JPIP browser support” every few days.

FWIW I agree with all of Paul’s criticisms of the currently proposed solutions and that a new file format should be a “north star.” And with all of the practical reasons why <picture> and srcset=”“ may be the best we can do in the short term (as long as we want to prefetch! See Matt Wilcox’s comment). I just find the notion that the problem can be fixed with “fewer images” preposterous (and “fuzzy images” isn’t much better).

Clutter is a design problem; serving scalable bitmaps cleanly and efficiently is a web problem.

Lee Kowalkowski

Whatever happened to the Progressive JPEG? Whilst the JPEG was downloading you could see the detail increase.

With my limited knowledge of this technology, it doesn’t seem a great leap to just have the browser stop downloading the JPEG once it has enough detail to render it?

Isn’t that all we’re after? Why make all the authors of the web go to all the trouble of the extra markup and artwork, when this is all that needs to happen?

David Goss

@Rudie

You’ve missed the point. Your solution is elegant but it doesn’t work because, as others have alluded to, of prefetching. By the time the CSS is parsed and your media query is run, the browser has long since requested the original src of the image and is busy downloading it.

The point is to find a solution without wasted bandwidth and unnecessary requests. We can swap sources from data- attributes now with JavaScript, but it doesn’t solve the problem.

- – -

I can’t speak for Mat, but I do think that much if the urgency behind picture is that we can’t just solve it with JavaScript (at least not very well) in the meantime and wait for a standards-based solution to come much later.

I also think that complaints about the verbosity of picture are overstated – Mat mentioned “hero” images and its worth remembering that picture is not supposed to supplant img entirely, just to be used where its really needed. It’s typically unlikely to be more than 1 or 2 images per page and 2 or 3 sources per image, if its used at all.

Eric Portis

@Paul Lloyd

That makes alot of sense, actually.

You’re arguing that the web should degrade to almost pure text with links to bandwidth-heavy, rich, much-harder-to-adapt-to-different-devices-than-a-block-of-text resources. And that depending on the device’s capabilities, let’s progressively load-in-place and enhance those resources from there.

I’m probably guilty of hearing “rich media doesn’t belong on the web” when you’ve actually been saying “rich media needs to degrade gracefully on the web.” Which of course is what we all want, and what we’re all here for.

One thing I hope everyone can agree on: rich media has been and will continue to be essential to the web.

I disagree that the tools we have to do this sort of progressive enhancement now are at all adequate or that their limits are acceptable or embraceable.

I don’t want to have to be careful, or clever. When I speak of making images first class citizens, I’m envisioning being able to produce, publish, and consume them as thoughtlessly as people publish <p>s, leaving browsers and devices to do the heavy lifting of progressive enhancement, deciding how many bits to move across the wire & how many pixels to push to the screen, such that users get the best possible experience. Right now this onus is put on users (see: flickr pages providing links to images at a range of resolutions) or developers (see: a thousand hacky javascripts & server-side solutions blooming.)

Can’t wait to see your code!

Rudie Dirkx

I agree completely! Especially 2. and 3. Media queries in HTML? Come on!

‘My’ solution is still the best, but you try to get someone to listen:

<pre>
<img src=“small.jpg” data-src-m=“medium.jpg” data-src-l=“large.jpg”>

@media (min-width: 900px) { img[data-src-l] { content: attr(data-src-l); }
}
</pre>

You’d almost think it already works, it’s that sensible.

Steve Souders

I thought this was a very well written article and explained exactly why in my blog post <a href=“http://www.stevesouders.com/blog/2012/12/14/a-good-blog-post/”>a good blog post</a>. Having read the comments I can see Paul has a history of good writing. We’re lucky.

bruce lawson

@Alex Morris

nice stuff, for webkit and Opera (which gets the small version that’s not specified in the img-set).

But IE and Firefox don’t support foo {content:} so they get nothing at all as the CSS doesn’t fill in an unresponsive fallback image, and there isn’t a src specified on the img element itself. If you do specify a src on the img element, then it’s prefetched before the CSS is downloaded, and you can end up downloading two images and only displaying one – exactly the use case for &lt;picture&gt;.

bruce lawson

Echoing what others said. picture and srcset aren’t beautiful (neither is much of HTML or the web stack). And verbosity is a problem.

A new image format will take ages. And content negotiation doesn’t work where there is no server (in an increasing number of environments such as epub, or an HTML front end to assets in kiosk etc).

I had sympathy with the idea that art direction is a CSS matter. But debating that is fruitless anyway; by the time the browser has the CSS, it’s already started to download the image that has an src in the markup.

The only way round this now is to use an empty div in the markup and use media queries to drag in a different background image using WebKit’s img-set http://blog.cloudfour.com/safari-6-and-chrome-21-add-image-set-to-support-retina-images/. That would lead to lots of content images being removed from content, added to the CSS layer so that they are visually there but have no alt text.

Alex Morris

@bruce would something like this be a viable option (for the future) in your opinion?

http://codepen.io/alexmorris/full/Ddejk

And divya extended it a little here

http://codepen.io/nimbupani/full/HkGhI

Mirco Jakse

applause, the suggested markup has been bothering me ever since i first saw it (them?), I completly agree that we need a better solution, lets not have bad/reduntant/excessive markup just because ‘a’ solution is needed.

Amber Weinberg

I actually agree with the point that I don’t consider images to be an issue at all in responsive design. I’ve never had a site so full of “large” images that had to be scaled down, that there was a huge hit in performance, and I’ve done some pretty large sites. Most of the images don’t get scaled down very much anyways, so the savings in performance is negligible. I’ve also yet to see a huge difference in quality between retina made images and not for the web – I mentioned this in my HandHeld conference talk, but it comes down to priorities. Is it worth all that extra time and code to make a million versions of your images? Is it worth downloading a double-sized image for retina? If it’s not pertinent to the site, I don’t waste the time or bandwidth.

David Bushell

@Eric Portis — totally agree, I’m guilty of too much UI-centric web design thinking here. For a website that is all about the rich media content, e.g. a photography portfolio, then this optimisation does become a bigger/more immediate problem as you’ve noted.

While a solution is being developed I still think it’s good advice to stick to standard resolution and less stock image dependant layouts. The proverbial 1mb person smiling at a salad sort of thing.

David Bushell

@Eric Portis

Hi Eric, since you’ve quoted me I’d like to note that I’m far from suggesting cutting the arm off — I’m saying leave the arm exactly how it is!

I certainly support the notion of a “web aesthetic” in the sense that we have to pay more attention to the limitations and opportunities of the medium. I’m not a proponent or romanticist in an all-typography web, but in this particular case of images, it’s my opinion that there really isn’t too much of a issue we need to “solve” right now. The bigger “fix” is avoiding design that requires overlay indulgent decorative styles. That’s what I mean about using less raster graphics. Consider repurposing the Windows Phone 8 over the iOS skeumorphic design style online — the first is inherently more suited to the web.

Ferdy

I’m personally a big fan of the compression approach as mentioned in the article. For JPEGs it has little to no cons and many pros. It works today.

In fact, it works so well that I find it superior to any new markup solution for which we have to wait years. As well-intended at those initiatives are, a single image approach will always work better in my belief. Ideally, that logic is in the browser or the format. We are very far away from that, so in the meanwhile I wonder if the compression trick isn’t favorable over new markup, at least for JPEGs.

James Tudsbury

I’ve been following the RICG for a while now and there isn’t much I can add to what other members have said here. Personally I think it’s understandable to suggest some of the solutions that only when looked at in more detail don’t seem possible.

I do think a responsive image format is the best solution, but for reasons pointed out above, it probably won’t happen, therefore we need a different solution and this has proved quite difficult to conjure up. I think the two solutions being looked at currently are the best we have, they solve the “art direction” issue well, which I think don’t think is a design/style issue as much as it a contextual one. Any images that can be changed via CSS without impacting context would most often be a background image anyway in my opinion.

The point about considering where we need images is a good one I think and ties into an attitude that I think exists with some designers/devs that media queries = responsive when in fact it is decisions like this that should all feed into the a responsive design. There is a good article about this on A List Apart if anyone fancies a read http://www.alistapart.com/articles/the-web-aesthetic/

Julian Kussman

I’ve discovered how to keep images art directed and with CSS only, no extra markup. Check out http://juliankussman.com/scaling . Here I use background-position in percentages to point to the focal point of the image.

(Disregarding the wasted bandwidth)

Niels Matthijs

Point 3 is truly essential. Media queries based on screen size are too limiting and make very little sense, the available size of an element is what could/should influence its behavior. Device/browser size is one of the influencing element, but there are much better options out there (explicit width on the element or width of its parent fe.)

Also the fact that responsive image syntax does NOT belong in html.

Paul Lloyd

@Eric Portis

For me, markup should be used to structure and communicate essential content—that which has value to the user arriving at a particular URL. This should degrade down to plain text because, like it or not, the web can be consumed in states where it is not visual. Thinking about pages this way, is actually useful because it can help us make decisions about what content is essential, is valuable.

An example. For a listing of story excerpts on a news site, an image for each story might not be considered essential content—remember, the story this excerpt links to would contain an image (on that particular URL, it might be considered valuable content). That image can still be accessed.

Take your example. As a gallery of visual work, it’s likely these visuals would be why people are visiting your site. Your work therefore is valuable content in this case. But that’s not to say full resolution images of this work are. Instead, you might want to provide smaller thumbnails, with links to larger resolution images, that users can then choose to view or not.

And in both these cases, what I describe here is the basic, resting state. We can progressively enhance up from this point, and make further, perhaps more nuanced decisions about what is valuable or not in different states.

Does this make sense? I’m going to put some of these ideas into code, as describing them in abstract is proving difficult.

Thanks for pushing back on what I’ve said here; if anything it is helping me clarify my points.

Paul Lloyd

@Scott Jehl: Thanks for your response Scott. I actually mentioned compressive images in this article (it’s linked to under point 1). This is a solution that personally I see having more legs. As I suggest, it’s hacking at the right part of the problem.

bruce lawson

@Alex Morris

nice stuff, for webkit and Opera (which gets the small version that’s not specified in the img-set).

But IE and Firefox don’t support foo {content:} so they get nothing at all as the CSS doesn’t fill in an unresponsive fallback image, and there isn’t a src specified on the img element itself. If you do specify a src on the img element, then it’s prefetched before the CSS is downloaded, and you can end up downloading two images and only displaying one – exactly the use case for &lt;picture&gt;.

Kevinjohn Gallagher

maybe we need to admit that “Responsive” isn’t a miracle fix; rather than attempting to create a fix/workaround for the fix/workaround in order to show horn it into the 9 years to write and still not finished HTML5 spec.

Dave

Like Mat I don’t really want to be that guy, but I feel I need express disappointment in this article.

24ways has long been a source of practicable methods and ideas – “goodness” as the blurb calls it – that help us designers and developers in demonstrable ways.

While the picture element and srcset attribute are both not great they are an option. Between the rock and hard place that are either A) adopting a less than great tech or B) waiting for something better, I think most of us would choose – and indeed already frequently practice – option A.

Don’t get me wrong, it’s nice to have a deep-n-meaningful from time to time, but I’ve heard the opinions in this piece from so many angles already, I was hoping for something a little more useful.

Dave

Impress us

Be friendly / use Textile