If you were to read a web designer’s Christmas wish list, it would likely include a solution for displaying images responsively. For those concerned about users downloading unnecessary image data, or serving images that look blurry on high resolution displays, finding a solution has become a frustrating quest.
Having experimented with complex and sometimes devilish hacks, consensus is forming around defining new standards that could solve this problem. Two approaches have emerged.
The <picture> element markup pattern was proposed by Mat Marquis and is now being developed by the Responsive Images Community Group. By providing a means of declaring multiple sources, authors could use media queries to control which version of an image is displayed and under what conditions:
<picture width="500" height="500">
<source media="(min-width: 45em)" src="large.jpg">
<source media="(min-width: 18em)" src="med.jpg">
<source src="small.jpg">
<img src="small.jpg" alt="">
<p>Accessible text</p>
</picture>
A second proposal put forward by Apple, the srcset attribute, uses a more concise syntax intended for use with the <img> element, although it could be compatible with the <picture> element too. This would allow authors to provide a set of images, but with the decision on which to use left to the browser:
<img src="fallback.jpg" alt="" srcset="small.jpg 640w 1x, small-hd.jpg 640w 2x, med.jpg 1x, med-hd.jpg 2x ">
Enter Scrooge
Men’s courses will foreshadow certain ends, to which, if persevered in, they must lead.
Ebenezer Scrooge
Given the complexity of this issue, there’s a heated debate about which is the best option. Yet code belies a certain truth. That both feature verbose and opaque syntax, I’m not sure either should find its way into the browser – especially as alternative approaches have yet to be fully explored.
So, as if to dampen the festive cheer, here are five reasons why I believe both proposals are largely redundant.
1. We need better formats, not more markup
As we move away from designs defined with fixed pixel values, bitmap images look increasingly unsuitable. While simple images and iconography can use scalable vector formats like SVG, for detailed photographic imagery, raster formats like GIF, PNG and JPEG remain the only suitable option.
There is scope within current formats to account for varying bandwidth but this requires cooperation from browser vendors. Newer formats like JPEG2000 and WebP generate higher quality images with smaller file sizes, but aren’t widely supported.
While it’s tempting to try to solve this issue by inventing new markup, the crux of it remains at the file level.
Daan Jobsis’s experimentation with image compression strengthens this argument. He discovered that by increasing the dimensions of a JPEG image while simultaneously reducing its quality, a smaller files could be produced, with the resulting image looking just as good on both standard and high-resolution displays.
This may be a hack in lieu of a more permanent solution, but it’s applied in the right place. Easy to accomplish with existing tools and without compatibility issues, it has few downsides. Further experimentation in this area should be encouraged, with standardisation efforts more helpful if focused on developing new image formats or, preferably, extending existing ones.
2. Art direction doesn’t belong in markup
A desired benefit of the <picture> markup pattern is to allow for greater art direction. For example, rather than scaling down images on smaller displays to the point that their content is hard to discern, we could present closer crops instead:
This can be achieved with CSS of course, although with a download penalty for those parts of an image not shown. This point may be negligible, however, since in the context of adaptable layouts, these hidden areas may end up being revealed anyway.
Art direction concerns design, not content. If we wish to maintain a separation of concerns, including presentation within our markup seems misguided.
3. The size of a display has little relation to the size of an image
By using media queries, the <picture> element allows authors to choose which characteristics of the screen or viewport to query for different images to be displayed.
In developing sites at Clearleft, we have noticed that the viewport is essentially arbitrary, with the size of an image’s containing element more important. For example, look at how this grid of images may adapt at different viewport widths:
As we build more modular systems, components need to be adaptable in and of themselves. There is a case to be made for developing more contextual methods of querying, rather than those based on attributes of the display.
4. We haven’t lived with the problem long enough
A key strength of the web is that the underlying platform can be continually iterated. This can also be problematic if snap judgements are made about what constitutes an improvement.
The early history of the web is littered with such examples, be it the perceived need for blinking text or inline typographic styling. To build a platform for the future, additions to it should be carefully considered. And if we want more consistent support across browsers, burdening vendors with an ever increasing list of features seems counterproductive.
Only once the need for a new feature is sufficiently proven, should we look to standardise it. Before we could declare hover effects, rounded corners and typographic styling in CSS, we used JavaScript as a polyfill. Sure, doing so was painful, but use cases were fully explored, and the CSS specification better reflected the needs of authors.
5. Images and the web aesthetic
The srcset proposal has emerged from a company that markets its phones as being able to browse the real – yet squashed down, tapped and zoomable – web. Perhaps Apple should make its own website responsive before suggesting how the rest of us should do so.
Converserly, while the <picture> proposal has the backing of a few respected developers and designers, it was born out of the work Mat Marquis and Filament Group did for the Boston Globe. As the first large-scale responsive design, this was a landmark project that ignited the responsive web design movement and proved its worth. But it was the first.
Its design shares a vernacular to that of contemporary newspaper websites, with a columnar, image-laden and densely packed layout. Compared to more recent examples – Quartz, The Next Web and the New York Times Skimmer – it feels out of step with the future direction of news sites. In seeking out a truer aesthetic for the web in which software interfaces have greater influence, we might discover that the need for responsive images isn’t as great as originally thought.
Building for the future
With responsive design, we’ve accepted the idea that a fully fluid layout, rather than a set of fixed layouts, is best suited to the web’s unpredictable nature. Current responsive image proposals are antithetical to this approach.
We need solutions that lack complexity, are device-agnostic and work within existing workflows. Any proposal that requires different versions of the same image to be created, is likely to have to acquiesce under the pressure of reality.
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. After years of gluttonous design practice, in which fast connections and expansive display sizes were an accepted norm, we have got use to filling pages with needless images and countless items of page furniture.
To design more adaptable experiences, the presence of every element needs to be questioned, for its existence requires additional data to be downloaded or futher complexity within a design system. Conditional loading techniques mean that the inclusion of images is no longer a binary choice, but can instead appear in a progressively enhanced manner.
So here is my proposal. Instead of spending the next year worrying about responsive images, let’s embrace the constraints of the medium, and seek out new solutions that can work within them.
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.
11/12/2012
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.
Vote Helpful or Unhelpful
11/12/2012
@junior wrote:
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.
Vote Helpful or Unhelpful
11/12/2012
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.
Vote Helpful or Unhelpful
11/12/2012
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.
Vote Helpful or Unhelpful
11/12/2012
+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.
Vote Helpful or Unhelpful
11/12/2012
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.
Vote Helpful or Unhelpful
11/12/2012
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.
Vote Helpful or Unhelpful
11/12/2012
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.
Vote Helpful or Unhelpful
11/12/2012
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
Vote Helpful or Unhelpful
11/12/2012
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
Vote Helpful or Unhelpful
11/12/2012
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.
Vote Helpful or Unhelpful
11/12/2012
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 :-)
Vote Helpful or Unhelpful
11/12/2012
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.
Vote Helpful or Unhelpful
11/12/2012
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 ;)
Vote Helpful or Unhelpful
11/12/2012
@David Bushell
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.
Vote Helpful or Unhelpful
14/12/2012
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.
Vote Helpful or Unhelpful
11/12/2012
@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.
Vote Helpful or Unhelpful
02/01/2013
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?
Vote Helpful or Unhelpful
11/12/2012
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.
Vote Helpful or Unhelpful
11/12/2012
@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.
Vote Helpful or Unhelpful
13/12/2012
@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!
Vote Helpful or Unhelpful
12/12/2012
@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.
Vote Helpful or Unhelpful
11/12/2012
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.
Vote Helpful or Unhelpful
11/12/2012
@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 <picture>.
Vote Helpful or Unhelpful
11/12/2012
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.
Vote Helpful or Unhelpful
11/12/2012
@Bruce yep it’s clearly not viable right now but it does do a few things well. would be a pain in the butt though for managing in a CMS
Vote Helpful or Unhelpful
11/12/2012
@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
Vote Helpful or Unhelpful
16/12/2012
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.
Vote Helpful or Unhelpful
11/12/2012
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.
Vote Helpful or Unhelpful
20/12/2012
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.
Vote Helpful or Unhelpful
13/12/2012
@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.
Vote Helpful or Unhelpful
11/12/2012
@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.
Vote Helpful or Unhelpful
11/12/2012
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.
Vote Helpful or Unhelpful
17/12/2012
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.
Vote Helpful or Unhelpful
11/12/2012
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/
Vote Helpful or Unhelpful
13/12/2012
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)
Vote Helpful or Unhelpful
12/12/2012
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.
Vote Helpful or Unhelpful
11/12/2012
@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.
Vote Helpful or Unhelpful
12/12/2012
Hey Paul,
Thanks – and sorry about that. You sure did. I’ll drink more coffee next time. :)
Vote Helpful or Unhelpful
11/12/2012
@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 <picture>.
Vote Helpful or Unhelpful
11/12/2012
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.
Vote Helpful or Unhelpful
11/12/2012
Dave: if you’ve “heard the opinions in this piece from so many angles already” then you’re not this article’s intended audience.
Thanks for stopping by.
Vote Helpful or Unhelpful
11/12/2012
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
Vote Helpful or Unhelpful
Impress us