Responsive web design & responsive images

[jasondrane]

Just my two cents, not that im a expert, BUT; I would build my site template using media queries and css. So that my site would simply scale down to a mobile browser.  For example,  http://cssgrid.net/.  That site is based off a 1140 grid that scales down based on the browser size.  just a thought!

apeisa: splitted this topic. To see history go: Any pointers on creating a mobile version of a site?

[Adam Kiss]

Jason, that might be not ideal, especially in cases when you want to serve platform-specific content (or platform-specific amount of content), otherwise reponsive wd might be the answer.

[apeisa]

I really like responsive designs, but as Adam said they are not always ideal. Consider image heavy frontpage of news site for example. Loading that amount of big images and scaling them down (or hiding) in css is not ideal at all (when good mobile optimized site would be just news headers and maybe one or two featured images).

[jasondrane]

I really like responsive designs, but as Adam said they are not always ideal. Consider image heavy frontpage of news site for example. Loading that amount of big images and scaling them down (or hiding) in css is not ideal at all (when good mobile optimized site would be just news headers and maybe one or two featured images).

I completely understand where you are coming from Apeisa. How I handle that is with a (max-width or min-width) media query call.  When the site scales down to a certain width, I have a different set of css called. That redesigns parts of the site to suit the new browser  widths

[ryan]

But that's just for assets loaded from CSS. On a dynamic and image heavy site, those images are usually coming from <img> tags, not from stylesheets. All the images would still get loaded in full, even if they were resized in CSS. My thought is that CSS image resizing would be really inefficient for an image heavy site... it doesn't seem acceptable. Is there a responsive solution for this? I can think of some hacks to achieve it, but am interested in best practices and am not yet full up-to-speed with RWD. I'm posting this as a real question because we're in the process of trying to determine whether to go responsive or mobile for villarental.com. I want to go responsive rather than mobile, but am concerned that I have to make major sacrifices to the mobile experience OR the desktop experience in order to do so. So I'm really conflicted as to what approach I should recommend.

[jasondrane]

I too am facing this dilemma, my full-time job with the state. We have looked at several different options and have settled on a highly modified version of responsive css like (getskeleton.com) AND a the incorporate of a img resizing function based in jquery.  Currently we are still working out the kinks in the img resize portion.

[ryan]

Based on what I understand so far, I think responsive is probably the clear way to go if you are starting from scratch on the entire site. Though that's not the case in my situation. The interest in the mobile version of the site came up after we were nearly done with the site.

If using javascript is acceptable, I suppose all the <img> tags could easily have their src attribute changed to reflect the screen width and one of a few different image sizes. Though the src attribute would probably have to point to some common placeholder initially since the browser initiates the image http request (I think?) right after it sees the <img> tag. Or of course, the <img> tags could just be written with javascript. But of course such a site would lack images if the client had no javascript... so less than ideal.

[apeisa]

My thought is that CSS image resizing would be really inefficient for an image heavy site... it doesn't seem acceptable. Is there a responsive solution for this? I can think of some hacks to achieve it, but am interested in best practices and am not yet full up-to-speed with RWD.

As far as I know all the current solutions pretty much hacks and not clear winner here. See this for example: http://filamentgroup.com/lab/responsive_images_experimenting_with_context_aware_image_sizing/.

For image heavy sites I would just go with separate mobile site and 100% freedom for markup.

[ryan]

Thanks, that makes sense. You know more about building responsive sites than anyone else I know, so I definitely trust your advice here.

That's a good link, though I'm not wild about their solution... <base> tags are something to be avoided, IMO. And something you'd have to be very careful with applying to an existing site. Even if inline javascript isn't kosher, wouldn't something like this be much more straightforward?

<script>img('/path/to/large.jpg', '/path/to/small.jpg', 'unicorn stampede');</script>
<noscript><img src='/path/to/large.jpg' /></noscript>

Then there would be that img() function in an included javascript file:

function img(large, small, alt) {
   var src = $(window).width() >= 480 ? large : small;
   document.write("<img src='" + src + "' alt='" + alt + "' />");  
}

[apeisa]

Ryan, looks like simplest solution I have seen so far! It might be that (some) browsers download images from noscript tags even with js enabled - this needs testing though. Or otherwise no-one has ever came with that solution (tried to google "responsive images noscript" with no success).

[ryan]

Tested in FF5, Chrome (latest), Safari on iPhone4 and IE8 and none of them download the image from the <noscript> unless javascript is specifically turned off. Confirmed by watching the requests live from the apache log. Seems encouraging that this approach would work. I haven't tried in older browsers, but I suspect the result would be the same... this tag has been around since the beginning. I also tried other HTML elements with an inline style background image and display: none; but no dice... the browser still loads those. I suppose this is pretty much what noscript was designed for in the first place, so might as well use it. But most will [hopefully] be seeing the <script> version of the image(s) instead. The downfall is mobile devices that don't support javascript... they'll get the full size image when we want them to get the small image. But then again, those devices probably don't support CSS3 media queries either.

[apeisa]

At the same time I was testing also: http://www.monoliitti.com/images/ (With similar results also, although just testing with desktop browsers on Win7).

Still amazed about elegance of this (and I really mean elegance, since all other solutions seems to be very very messy...). Usually it is that simplest solutions are hardest to find...

---

The downfall is mobile devices that don't support javascript... they'll get the full size image when we want them to get the small image.

Well... I think that the super nice thing about this is that you can even choose your default. You might as well serve small image inside <noscript> and serve high quality images only for js-enabled and big resolution browsers. Think about this:

<script>img('Big.jpg', 'Small.jpg', 'Alt');</script>
<noscript><img src='Small.jpg' /><p><a href='Big.jpg'>Click to see bigger image</a></p></noscript>

[Edit by Adam] Gluing doubple posts together. Again

[ryan]

I searched for "responsive images noscript" and found this. Looks like they are using the same noscript fallback, though quite a different solution for the responsive image... kind of like what we were talking about before with a placeholder image that has the src attribute replaced with JS. Only problem I can see with this is that you'd be left with a placeholder and a full size image for the fallback, rather than just the full size image.

http://www.jamesfairhurst.co.uk/posts/view/responsive_images_with_php_and_jquery/

As a side note, the ajax/PHP side of this article is pretty insane from a resources and/or security standpoint. If they aren't caching the files to disk, then someone could kill the server by making a a few hundred image requests in a minute (simplest DDOS attack ever). If they are caching the images, then they could feasibly end up with thousands of files per image, and fill up the server's hard drive pretty quickly.

[apeisa]

Oh, I did stumble on that, but somehow missed noscript part of it. Just went to demo and wasn't impressed.

I think that we have clear winner here

[ryan]

<noscript><img src='Small.jpg' /><p><a href='Big.jpg'>Click to see bigger image</a></p></noscript>

Good point, and great idea!

[apeisa]

Ryan, I developed your idea a little bit further: http://www.monoliitti.com/images/

You just need this in your html:

<noscript data-large='Koala.jpg' data-small='Koala-small.jpg' data-alt='Koala'><img src='Koala.jpg' alt='Koala' /></noscript>

Tiny jQuery snippet does the heavy lifting and creating all the img tags.

EDIT: Tested only with high-end desktop browsers and with my android. My HTC Desire HD default browser fails to load small images, since it fakes it's resolution (same problem with other solutions that rely on screen.width). But other browsers work just fine.

[ryan]

Looking good! I used to think that a <noscript> could only appear if it immediately followed a </script> tag, but now I see that's definitely not the case. If the large image is always in the <noscript> tag, I suppose we could even get by not having a separate attribute for that one (the jQuery could just grab it out of the $("noscript").html("img").attr("src"); But then again, probably best not to make assumptions about what someone is doing inside the <noscript> (like if they are showing a thumbnail linked to the large image, as you mentioned before).

One other possible thing to do would be to use jQuery to hook into the $(window).resize(function() { ... }); and change the src attribute consistent with the window size. But that's probably only useful when dragging small to large (unlikely or impossible on a mobile device), as there's little reason to replace the large image once it's loaded. On the other hand, it does make the effect easier to see in a demo.

[fenton]

hi guys,

that's an iteresting approach! how could this be used with content-images, inserted via wysiwyg editor?

cheers, j

[ryan]

You could hook into $page->render() and replace the <img> tags with the responsive version. Though I'm not sure I'd bother with inline wysiwyg images because you aren't really dealing with predefined sizes here like you would be outside of it.

If responsive images in this context were a really common need, I would probably just code the image plugin to output it in the manner we needed, with noscript tags. But I don't think it's quite common enough to warrant providing that option, yet. I would be more inclined to take a CSS percentage resizing approach for less defined images like those in a wysiwyg field.

[fenton]

Hi Ryan,

well, haven't built a responsive site so far, only read a couple of articles, so i'm not too savey on that topic:)

Commonly i would predefine (or tell the client) to only use 2 sizes of images to be inserted in the content, because many different sized images would look odd, i think.

i assume loading time would definitely benefit, if you only need to load the small version of an image for the mobile site.

thanks, jan

[ryan]

Jan,

I've found it's hard to constrain the client's "creativity" in a rich text editor, whether with images, type or anything like that. So I generally prefer to just provide them with an upload field and let my template handle the placement and size of the image. But placing images with the rich text editor is sure handy, in disciplined hands. Short of modifying TinyMCE or the plugins, the best way I can think of to bolt-on this type of responsive image would be to hook into Page::render and perform a live (pre-render) replacement of the image tags with the responsive versions.

You might also want to look at a solution like http://responsive-images.com, which operates on the original <img> tag and thus is very portable to bolt in just about any situation. It's quite a nice system the author has built. The only big compromise with this (and other similar solutions) is that they don't use the <noscript> solution we were talking about earlier. As a result, the browser is actually loading both large and thumbnail images and swapping in one or the other. The bandwidth consumed is greater than if you just loaded the large image itself. So simple CSS resizing may be more efficient, depending on your need. But certainly the browser will feel faster when displaying the small version (at least, after both images have loaded), and I think that's the real benefit for solutions like that.

The benefit of the <noscript> solution discussed in this thread is that it doesn't have to load both images–a major advantage on mobile and low-bandwidth devices. But the disadvantage is that it requires a <noscript> tag in addition to an <img> tag, so it's not as easily plugged into existing situations, like a rich text editor.

[fenton]

Ryan, thanks for your reply!

You might also want to look at a solution like http://responsive-images.com ... As a result, the browser is actually loading both large and thumbnail images and swapping in one or the other.

i'm a bit confused, because he actually says on his website:

Why? Because your site is being increasingly viewed on smaller, slower, low bandwidth devices. Your desktop-centric images load slowly, cause UI lag, and cost your visitors un-necessary bandwidth and money.

do you know in what way bandwidth is actually saved with his approach?

thanks, jan

[ryan]

My experience so far is that this method doesn't save any bandwidth, it actually increases it. Here's one way to test:

1. Open Chrome (or Firefox, or any browser where you can monitor activity).

2. Open the browser activity window. In Chrome that's: View > Developer > Developer Tools > Network

3. Size your window to as small as you can, to ensure it targets the smallest image size. Then load responsive-images.com.

4. Watch your activity window. Notice that the browser downloads both the large 205k image (/content/images/creepy.jpg) and the 26k thumbnail (/content/images/thumbnails/thumbnail.jpg), even though only the thumbnail is ultimately displayed.

5. Click in some of the other thumbnails and notice that only the large image is loaded (though seems like they could fix that part though, since it's JS driven).

Try loading the site on your mobile device (outside of wifi) and notice how long it takes to load–it appears be loading the 200k image, though no activity window to confirm it on my iPhone.

The reason it loads both the large and small is because the browser starts downloading the large image as soon as the <img> tag appears, before JS can change it. My impression is that there is no way to avoid consuming the bandwidth of the image present in the src attribute of an <img> tag, unless it's contained in a <noscript> tag.

[fenton]

i just tried it with FF & checked with the Webdeveloper Bar, actually it only loads the right image. maybe you need to clear the cookies first?

*see screenshot, i even didn't delete the cookie for this one

[ryan]

I tried in Firefox this time with Firebug. Cleared my cache and cookies. Then loaded it, ensuring the browser window was as narrow as it would go ahead of time.

Got something really interesting this time–830k for creepy.jpg! Not sure what that's about? That can't be right. Maybe a typo by Firebug or am I reading this incorrectly? (see 1st screenshot)

Reloading again gets me the normal 205k image (2nd screenshot). My browser window was set at the smallest width it would go the entire time (see screenshots).