I don’t see what the big deal is, both the img and picture variations are hard to use and will largely be ignored by authors, since most web content is authored by software. Has anyone thought of the fact that all CMS systems worldwide are going to have to spit out various image sizes and update their WYSIWYG editors to include this new markup? How long do you figure will that take?
The other issue I’m seeing, unless I’m missing something, is the seemingly hard coupling of device resolution to image size. It’s missing a lot of context. Just because my device has a high resolution doesn’t mean I’m on broadband. Even if I am on broadband, it could be expensive. Only the combination of resolution, connection speed and connection costs begins to define the user’s actual context.
Therefore, I fully agree with Scott’s remark (#1). Don’t bother authors with this. Let software do it, progressively and intelligently.
One often forgotten user group seems to be getting ignored in this debate and that is the non-developers who have to write simple code when updating pages.
Keep in mind, non-developers in most circumstances—and certainly in the circumstance of a sophisticated responsive design—will update the content via a CMS. They won’t have to craft multiple images: their design team will do that, or the CMS will do it algorhythmically. The most complicated thing a non-designer might have to do is check a few checkboxes in the CMS. :)
As usual, Mr Keith (AKA @adactio) is the cluefullest person in the room when it comes to the sexual politics of HTML5.
His “chronology of what went wrong”:http://adactio.com/journal/5474/ and evaluation of the merits of the various proposals is definitely worth reading today.
Once again the ongoing community-based evolution of the web has provided developers the opportunity to help form the foundations for future development. The incentive here is as good as any for individual developers and designers to step forward and make a lasting improvement and contribution to web standards for years to come.
Gabrielso: It turns we’re not able to add elements inside of an `img` tag. Where it’s a self-closing tag, we’ve been told by several browser folks that it can’t be made to “look ahead” for alternate sources before closing itself. I can’t claim to understand how that works on the implementor side, but we’ve been told that a number of times. The same applies to “image”, which is an alias of “img” in a surprising number of browsers.
corey: Turns out we can’t use `image`. Since time immemorial, browsers have treated `image` as an alias of `img` — even many modern browsers still do this, as it turns out. If we used `image` it would be subject to all the same complications as `img`.
rachelreveley: There’s a lot of conversation around that going on as we speak. It could go either way, really. `picture` wouldn’t replace common `img` tags everywhere; it would mostly be used for large hero images, like the ones seen on Apple.com. The general use would be only a few per page — and even then, having all that consolidated in the head could get pretty unwieldy. On the other hand, it would mean just as much markup down in the `body` otherwise. Matt Wilcox is a big proponant of the `head`-based approach — his “post”:http://mattwilcox.net/archive/entry/id/1091/ on the subject is well worth a read.
The important thing is that we have a chance to discuss these kinds of potential improvements in a productive, meaningful way. If the WHATWG proposal were pushed through by a few key players, we may never have a chance to put these kinds of suggestions to use.
Luke Stevens: Well, as you can probably tell: I’m not above starting a little bit of trouble. But “equal partners” is definitely the goal, and as you said: that means finding a way to make sure we have an equal say.
I believe in web standards; I do. The process may be a little skewed right now, but the more of us that get involved in the creation of the standards the less skewed the process will become. We could likely find ways to work around the WHATWG, but we’ll get more done together — we just need to have a larger presence in these discussions, and we can only get that by showing up.
What about using HTML data attributes? Unfortunately it would require a little help via JS, but then you’re not limited to specific tags for sizing. I agree that the creation of an additional tag is redundant since we already have <img>.
ex:
300×300.jpg
or
desktop.jpg
Just a thought… I think the bigger issue is thinking ahead to the devices and screens we’ll be developing for in the near future, ex: tv, movie theaters, auto industry, etc.
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”:http://www.zeldman.com/2012/05/17/editor-vs-constituencies/
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.
beatriz800000
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.
davidzuch
I think “tesmond”:http://www.alistapart.com/comments/responsive-images-and-web-standards-at-the-turning-point/P10/#19 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”:http://www.alistapart.com/comments/responsive-images-and-web-standards-at-the-turning-point/P10/#15 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.
Mwahaha
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:
https://vimeo.com/38947881
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.
Jon Wolski
Gabrielso beat me to the punch on recommending the object element. This has been around for over a decade and supports fallback content.
e.g.
<object type=“image/webp” data=”[src_url].webp”>
<object type=“image/javascript;responsive” data=”[src_url].jpeg”>
[src_url].jpg
</object>
</object>
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
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 (http://www.jpegmini.com)
I find it hard already to keep up with “standards”.
Cheers
Micha
Copy & paste the code below to embed this comment.
Mathew Robertson
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).
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.
Riquez
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.
41 Reader Comments
Back to the ArticleRégis Kuckaertz
Let’s try again. Responsive images:
<img src=“image.jpeg” alt=”” responsive>
Overriding UA content negotiation:
<img src=“image.jpeg” alt=”” responsive onbeforeload=“negotiate(event)”>
:)
fchristant
I don’t see what the big deal is, both the img and picture variations are hard to use and will largely be ignored by authors, since most web content is authored by software. Has anyone thought of the fact that all CMS systems worldwide are going to have to spit out various image sizes and update their WYSIWYG editors to include this new markup? How long do you figure will that take?
The other issue I’m seeing, unless I’m missing something, is the seemingly hard coupling of device resolution to image size. It’s missing a lot of context. Just because my device has a high resolution doesn’t mean I’m on broadband. Even if I am on broadband, it could be expensive. Only the combination of resolution, connection speed and connection costs begins to define the user’s actual context.
Therefore, I fully agree with Scott’s remark (#1). Don’t bother authors with this. Let software do it, progressively and intelligently.
Jeffrey Zeldman
rachelreveley wrote:
Keep in mind, non-developers in most circumstances—and certainly in the circumstance of a sophisticated responsive design—will update the content via a CMS. They won’t have to craft multiple images: their design team will do that, or the CMS will do it algorhythmically. The most complicated thing a non-designer might have to do is check a few checkboxes in the CMS. :)
Jeffrey Zeldman
As usual, Mr Keith (AKA @adactio) is the cluefullest person in the room when it comes to the sexual politics of HTML5.
His “chronology of what went wrong”:http://adactio.com/journal/5474/ and evaluation of the merits of the various proposals is definitely worth reading today.
Paul Geronca
Once again the ongoing community-based evolution of the web has provided developers the opportunity to help form the foundations for future development. The incentive here is as good as any for individual developers and designers to step forward and make a lasting improvement and contribution to web standards for years to come.
Mat Marquis
Gabrielso: It turns we’re not able to add elements inside of an `img` tag. Where it’s a self-closing tag, we’ve been told by several browser folks that it can’t be made to “look ahead” for alternate sources before closing itself. I can’t claim to understand how that works on the implementor side, but we’ve been told that a number of times. The same applies to “image”, which is an alias of “img” in a surprising number of browsers.
Mat Marquis
corey: Turns out we can’t use `image`. Since time immemorial, browsers have treated `image` as an alias of `img` — even many modern browsers still do this, as it turns out. If we used `image` it would be subject to all the same complications as `img`.
Mat Marquis
rachelreveley: There’s a lot of conversation around that going on as we speak. It could go either way, really. `picture` wouldn’t replace common `img` tags everywhere; it would mostly be used for large hero images, like the ones seen on Apple.com. The general use would be only a few per page — and even then, having all that consolidated in the head could get pretty unwieldy. On the other hand, it would mean just as much markup down in the `body` otherwise. Matt Wilcox is a big proponant of the `head`-based approach — his “post”:http://mattwilcox.net/archive/entry/id/1091/ on the subject is well worth a read.
The important thing is that we have a chance to discuss these kinds of potential improvements in a productive, meaningful way. If the WHATWG proposal were pushed through by a few key players, we may never have a chance to put these kinds of suggestions to use.
Mat Marquis
Luke Stevens: Well, as you can probably tell: I’m not above starting a little bit of trouble. But “equal partners” is definitely the goal, and as you said: that means finding a way to make sure we have an equal say.
I believe in web standards; I do. The process may be a little skewed right now, but the more of us that get involved in the creation of the standards the less skewed the process will become. We could likely find ways to work around the WHATWG, but we’ll get more done together — we just need to have a larger presence in these discussions, and we can only get that by showing up.
nolfranklin
What about using HTML data attributes? Unfortunately it would require a little help via JS, but then you’re not limited to specific tags for sizing. I agree that the creation of an additional tag is redundant since we already have <img>.
ex:
300×300.jpg
or
desktop.jpg
Just a thought… I think the bigger issue is thinking ahead to the devices and screens we’ll be developing for in the near future, ex: tv, movie theaters, auto industry, etc.
Jeffrey Zeldman
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”:http://www.zeldman.com/2012/05/17/editor-vs-constituencies/
Enjoy (and feel free to disagree).
Charlie Clark
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>
beatriz800000
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.
davidzuch
I think “tesmond”:http://www.alistapart.com/comments/responsive-images-and-web-standards-at-the-turning-point/P10/#19 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”:http://www.alistapart.com/comments/responsive-images-and-web-standards-at-the-turning-point/P10/#15 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.
Mwahaha
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:
https://vimeo.com/38947881
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:
http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/
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.
Jon Wolski
Gabrielso beat me to the punch on recommending the object element. This has been around for over a decade and supports fallback content.
e.g.
<object type=“image/webp” data=”[src_url].webp”>
<object type=“image/javascript;responsive” data=”[src_url].jpeg”>
[src_url].jpg
</object>
</object>
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
Osvaldo
The option looks much better. I fully agree that we need consistency with the video and audio tags.
migo33
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 (http://www.jpegmini.com)
I find it hard already to keep up with “standards”.
Cheers
Micha
Mathew Robertson
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).
ivancamilov
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.
Riquez
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.