All these approaches put to much of a burden on developers! They’re clunky, prone to breakage and force the use of more markup. But maybe worst of all they force you to define fixed dimensions where you switch the image and to maintain multiple versions of the image!
I’m really quite astonished that no one so far has mentioned that JPEG 2000 together with the JPIP protocol handles this use case already… Store the image on the server in the maximum resolution you want to offer, but just download a size appropriate for the user’s display. Open source JPIP servers are available… (Djatoka for instance can serve ‘regular’ formats from a jp2 file, providing a fallback.) Better native support for JPEG 2000 in browsers would be nice of course.
Some experiments need to be done on how best to use inline JPEG 2000 for responsive images. I suppose one approach could be sending a scaling factor (or max size) with a cookie and do some URI rewriting on the server side to get the desired image size. CSS can still be used to downscale the image for a perfect fit. It’s not optimal, but the main point is to just work with one image and let the server handle the scaling.
Yes, JPEG 2000 requires encoders/decoders that are complex and more computationally ‘demanding’. But there has to be a tradeoff somewhere.
And let’s not forget that JPEG 2000 offers many other useful features.
I wrote the comment above in a hurry and forgot to clarify that of course no browser currently implements the JPIP protocol. However I still think using a JPEG 2000 server over HTTP could be a very interesting method towards solving the problem of responsive images. And it would certainly help push native implementations of the JPEG 2000 standard.
Copy & paste the code below to embed this comment.
JCOELHO
What about an approach of using the CSS media type to control the image source? No JavaScript involved, but it does assume that mobile devices come up with a media type of handheld. You probably can’t use the img tag, but maybe a div tag. Then again it changes the function of the div tag and is not semantically correct. A change to the markup to support images like videos would still be the best option.
I’ve been experimenting with this, . I watched the resources as I expanded the window and the different image for the widest display isn’t requested until that CSS is triggered by the window reaching each specified width. (I cused different images so I could see the change easily).
I agree, a picture tag was perfect to solve this problem, we have a solution for this, but this solution is not easy to implement, and, at this time, we have to care about many device sizes more and more. Hey W3C, look this post! :P
@Marc Diethelm: This is entirely the best solution. I’ve written about it as the “perfect solution” in my blog post. The problem is, that JPEG2000 isn’t that good of a format for graphics. So we would need ideally WebP/WebM to be able to progressively download and serve responsive images. Until that is implemented in all browsers (haha!) you will still need another approach, so that’s why we proposed the HTML5 solution for interim.
JCOELHO, yeosteve: A CSS only solution wouldn’t work as it’s not semantic and doesn’t work valid. It still should be possible to do via CSS for non-semantic (styling/layout) purposes, too. Mailing list of W3C didn’t care about this very much ;)
@Anserson Schmitt: We (Mat and I) are currently discussing on WHATWG lists and if we have a solution over there, it will move to the W3C list. So be sure we do our best W3C cares about this problem :)
@ NatCk: adaptive-images.com is only a polyfill solution and uses some technique not very good for a standard-solution.
Since we’re talking about changing the browser’s behavior anyway, why not actually make it offer up the information to properly solve this problem server-side? Let’s have the browser send the information that is available to the “css media queries”:http://www.w3.org/TR/css3-mediaqueries/ in the HTTPGET request headers caused by the one-and-only whatever.png tag or CSS url(“whatever.png”).
To wit:
X-Media: “screen color:24 resolution:120dpi orientation:portrait device:640×480 viewport:500×300”
(obviously, the aspect-ratio and device-aspect-ratio can be computed, color-index seems meh)
The nice thing about this is that it is really up to the user-agent’s current needs to determine what should be displayed, thus what should be requested. If someone zooms in, the user-agent can ask for a bigger version. If they switch to print view, we can ask for the monochrome version in higher DPI and all is warm and fuzzy. If the server doesn’t care, it serves up the one-true-image. If the server cares, it can serve specific versions. Cache logic can be driven by the standard content-negotiation logic (and left non-cached until it is).
The best part of ALL of this is that the CSS can just reference an image, the html can just include a img tag, etc… and the browser’s request can be driven by what it knows already about the size/placement/device of the image.
Use JavaScript stylesheet manipulation. All responsive images should be rendered in an <img> with a token classname, such as ‘responsive’, and should have fallback ‘src’ value. In <head>, JS will add a stylesheet rule to ‘display:none’ all such elements (to avoid requesting the wrong image resource), then will determine the appropriate screen size category. Script block at the bottom of the page will alter ‘src’ values of all responsive <img>s according to screen size category, per some naming convention, and then update stylesheet rule to ‘display:inline’ all such elements.
This may cause flicker, more noticeable when HTML is generated/delivered slowly. This can be mitigated by encapsulating the responsive <img> in some server-side component that also emits a script block right after each <img> to do the ‘src’ attribute manipulation and displaying.
The ‘resize’ event will be handled to perform this logic in case different images need to be re-rendered (can be short-circuited if new image would have lower quality).
If UA doesn’t support JS or doesn’t support stylesheet manipulation, there will be flicker or simply the fallback content is rendered.
This one is an inspiration personally to uncover out rather more related to this subject. I must confess your information extended my sentiments as well as I am going to proper now take your feed to stay updated on every coming blog posts you would possibly possibly create. You are worthy of thanks for a job perfectly carried out!
The “Responsive Content”:http://stephanfowler.github.com/responsive-content/ jQuery plugin is an approach which works in a “coarse grained” way, ajax-loading an entire HTML fragment into the page, given current window width (and pixel density). It can be used to tell the server to supply appropriately sized image src URLs etc.
It’s a fork of Github’s Pjax loader. It does not rely on User Agent or cookies – just window width.
Copy & paste the code below to embed this comment.
DanMcRae
How do would you appreciate these 2 solutions to download only the small images when needed (Smartphone, iPhone, Android)
1) Use $_SERVER(‘HTTP_USER_AGENT’) in the server script to detect that it is not a PC
2) Have a main page that detects the screen size and pass it in the URI for subsequent pages.
75 Reader Comments
Back to the ArticleMarc Diethelm
All these approaches put to much of a burden on developers! They’re clunky, prone to breakage and force the use of more markup. But maybe worst of all they force you to define fixed dimensions where you switch the image and to maintain multiple versions of the image!
I’m really quite astonished that no one so far has mentioned that JPEG 2000 together with the JPIP protocol handles this use case already… Store the image on the server in the maximum resolution you want to offer, but just download a size appropriate for the user’s display. Open source JPIP servers are available… (Djatoka for instance can serve ‘regular’ formats from a jp2 file, providing a fallback.) Better native support for JPEG 2000 in browsers would be nice of course.
Some experiments need to be done on how best to use inline JPEG 2000 for responsive images. I suppose one approach could be sending a scaling factor (or max size) with a cookie and do some URI rewriting on the server side to get the desired image size. CSS can still be used to downscale the image for a perfect fit. It’s not optimal, but the main point is to just work with one image and let the server handle the scaling.
Yes, JPEG 2000 requires encoders/decoders that are complex and more computationally ‘demanding’. But there has to be a tradeoff somewhere.
And let’s not forget that JPEG 2000 offers many other useful features.
Marc Diethelm
I wrote the comment above in a hurry and forgot to clarify that of course no browser currently implements the JPIP protocol. However I still think using a JPEG 2000 server over HTTP could be a very interesting method towards solving the problem of responsive images. And it would certainly help push native implementations of the JPEG 2000 standard.
JCOELHO
What about an approach of using the CSS media type to control the image source? No JavaScript involved, but it does assume that mobile devices come up with a media type of handheld. You probably can’t use the img tag, but maybe a div tag. Then again it changes the function of the div tag and is not semantically correct. A change to the markup to support images like videos would still be the best option.
yeosteve
I’ve been experimenting with this, . I watched the resources as I expanded the window and the different image for the widest display isn’t requested until that CSS is triggered by the window reaching each specified width. (I cused different images so I could see the change easily).
No Javascript at all.
.rightBox{
display:none;
width:40%;
background-size:contain;
background-repeat:no-repeat;
float:right;
overflow:auto
}
@media screen and (orientation:landscape) and (min-width:480px){
.rightBox{
display:block;
height:40%;
background-image:url(’../images/mobile/sevenstep.jpg’);
}
}
@media screen and (orientation:landscape) and (min-width:1024px){
.rightBox{
display:block;
height:40%;
background-image:url(’../images/full/planning.jpg’);
}
}
Anderson Schmitt
I agree, a picture tag was perfect to solve this problem, we have a solution for this, but this solution is not easy to implement, and, at this time, we have to care about many device sizes more and more. Hey W3C, look this post! :P
anselmh
@Marc Diethelm: This is entirely the best solution. I’ve written about it as the “perfect solution” in my blog post. The problem is, that JPEG2000 isn’t that good of a format for graphics. So we would need ideally WebP/WebM to be able to progressively download and serve responsive images. Until that is implemented in all browsers (haha!) you will still need another approach, so that’s why we proposed the HTML5 solution for interim.
JCOELHO,yeosteve: A CSS only solution wouldn’t work as it’s not semantic and doesn’t work valid. It still should be possible to do via CSS for non-semantic (styling/layout) purposes, too. Mailing list of W3C didn’t care about this very much ;)@Anserson Schmitt: We (Mat and I) are currently discussing on WHATWG lists and if we have a solution over there, it will move to the W3C list. So be sure we do our best W3C cares about this problem :)
@ NatCk: adaptive-images.com is only a polyfill solution and uses some technique not very good for a standard-solution.
IDisposable
Since we’re talking about changing the browser’s behavior anyway, why not actually make it offer up the information to properly solve this problem server-side? Let’s have the browser send the information that is available to the “css media queries”:http://www.w3.org/TR/css3-mediaqueries/ in the HTTP GET request headers caused by the one-and-only whatever.png tag or CSS url(“whatever.png”).
To wit:
X-Media: “screen color:24 resolution:120dpi orientation:portrait device:640×480 viewport:500×300”
(obviously, the aspect-ratio and device-aspect-ratio can be computed, color-index seems meh)
The nice thing about this is that it is really up to the user-agent’s current needs to determine what should be displayed, thus what should be requested. If someone zooms in, the user-agent can ask for a bigger version. If they switch to print view, we can ask for the monochrome version in higher DPI and all is warm and fuzzy. If the server doesn’t care, it serves up the one-true-image. If the server cares, it can serve specific versions. Cache logic can be driven by the standard content-negotiation logic (and left non-cached until it is).
The best part of ALL of this is that the CSS can just reference an image, the html can just include a img tag, etc… and the browser’s request can be driven by what it knows already about the size/placement/device of the image.
lunalot
Use JavaScript stylesheet manipulation. All responsive images should be rendered in an <img> with a token classname, such as ‘responsive’, and should have fallback ‘src’ value. In <head>, JS will add a stylesheet rule to ‘display:none’ all such elements (to avoid requesting the wrong image resource), then will determine the appropriate screen size category. Script block at the bottom of the page will alter ‘src’ values of all responsive <img>s according to screen size category, per some naming convention, and then update stylesheet rule to ‘display:inline’ all such elements.
This may cause flicker, more noticeable when HTML is generated/delivered slowly. This can be mitigated by encapsulating the responsive <img> in some server-side component that also emits a script block right after each <img> to do the ‘src’ attribute manipulation and displaying.
The ‘resize’ event will be handled to perform this logic in case different images need to be re-rendered (can be short-circuited if new image would have lower quality).
If UA doesn’t support JS or doesn’t support stylesheet manipulation, there will be flicker or simply the fallback content is rendered.
katerpiddah
Is there a reason why you can’t just use images as the source in the video tag with the image MIME type, as in the following example??
<video>
<source src=“high-res.jpg” media=“min-width:800px” type=“image/jpeg”>
<source src=“low-res.jpg” type=“image/jpeg”>
poster.jpg
</video>
Thanks.
sminfosoft10
This one is an inspiration personally to uncover out rather more related to this subject. I must confess your information extended my sentiments as well as I am going to proper now take your feed to stay updated on every coming blog posts you would possibly possibly create. You are worthy of thanks for a job perfectly carried out!
“Web Design Company”:http://www.sminfosoft.com
“Technology News”:http://update-technologynews.blogspot.in/
lerouxb
What do you think of my responsive images proposal?
http://opensores.za.net/2012/responsive-images/
stephanfowler
The “Responsive Content”:http://stephanfowler.github.com/responsive-content/ jQuery plugin is an approach which works in a “coarse grained” way, ajax-loading an entire HTML fragment into the page, given current window width (and pixel density). It can be used to tell the server to supply appropriately sized image src URLs etc.
It’s a fork of Github’s Pjax loader. It does not rely on User Agent or cookies – just window width.
stephanfowler
Correstion. Correct url:
http://responsivecontent.net/
Jessica Wilson
But, Do I Need Responsive Website For Growth of My Business?
DanMcRae
How do would you appreciate these 2 solutions to download only the small images when needed (Smartphone, iPhone, Android)
1) Use $_SERVER(‘HTTP_USER_AGENT’) in the server script to detect that it is not a PC
2) Have a main page that detects the screen size and pass it in the URI for subsequent pages.