Responsive web design with Concrete 5

Permalink 1 user found helpful
Hi Guys,

I'm working with a colleague on a project for a really cool company and they want us to go wild with CSS3 & basically stick two fingers up to browsers which don't support but also to be a responsive layout.

Now we've gotten the Skeleton grid system themed in as a blank canvas but we were wondering about making images responsive and serving up different versions for different screen sizes. has anyone done something like this or is there anything out there that we may be able to use for this?


View Replies:
beebs93 replied on at Permalink Reply
Sencha (formerly tinySrc) has a cool API that adapts images to screen sizes. I've only used it once [ ] and overall it worked pretty nicely.

I'm not sure about Sencha, but before when they were tinySrc the maximum size of returned images was ~980px so if you wanted to feed it a 1200x50px banner for instance it'd be returned with 980 x 41 regardless of the current viewport. I don't know if that's been addressed or not in this new version, though.
PassionForCreative replied on at Permalink Reply
Hey Beebs

I see this site is a WP site, how did you add the function to apply to each image. I'm wondering how I would add the URL dynamically to images that the client adds thru concrete5?

Hope someone out there may be able to help.

beebs93 replied on at Permalink Reply
For the post images themselves I simply ran the content (from get_the_content()) through a basic DOM parser, prepended the API URL to any image's "src" attribute, saved the output, applied the normal WP content filters and echoed the result (it's a lot simpler than it sounds).

For C5 I would imagine making your own copy of the image block in the SITE_ROOT/blocks directory and slightly modifying the view.php to prepend the appropriate API URL.

P.S. Also, unless Sencha changed this, you couldn't feed it a .GIF file without specifying a different file format you wanted the returned image in.

With JPGs and PNGs you could simply do:

<API URL HERE>/<path to your image here> and it would return the re-sized image in whatever format you gave it.

For GIFs you'd have to:

<API URL HERE>/png/<path to your image here> which basically says "Take my .gif file, resize it and return it as a PNG".
PassionForCreative replied on at Permalink Reply
So based on this, should I then create a custom template (or modify the code of additional blocks) to append the sencha URL to each instance of an image being added?
beebs93 replied on at Permalink Reply
Well, if we're in our own little vacuum here, I'd probably make a simple image block where you had the option to append the API url to the image (via a checkbox or something).

Why the option? Most of the images would need to be re-sized, but I wouldn't want to lock myself in like simply modifying the view.php as I suggested earlier would. Off the top of my head, I cannot think of a specific situation where you wouldn't want the image re-sized based on viewport, but I haven't built enough progressively-enhanced responsive websites to assume such a thing.

In truth, adaptive image sizing with Sencha was designed to help mobile users avoid downloading uber large images, but still have a similar experience as desktop users. If you're only going with CSS3 (and I assume HTML5) the mobile users are going to be screwed over a long time before the images come into play.

If you're only worrying about desktop browsers (and even then only the fraction that support CSS3 & HTML5) why worry about re-sizing images for small screen sizes?

As riotaj mentioned, if you're only gunning for responsive web design, Sencha will only help you on the initial page load; once you start re-sizing the browser window you're still stuck with the initial problem: dynamically re-sizing media. While there are options to help make this easier, they do require some effort to get them to work properly.
adamjohnson replied on at Permalink Reply
Therein lies the issue with responsive web design: sizing media. Sencha reads like a good option and I'm fairly certain there are several solutions to the problem (hello google). That said, if you are using the images in your CSS, mobile browsers will only download the images in their media query (that is, IF there is a background image in the media query that's overriding a larger image outside of it).
Responsive replied on at Permalink Reply
would the following work

<img alt="butterfly">
<source src="butterfly-small.png" media="max-device-width:480px" />
<source src="butterfly-large.png" media="min-device-width:481px" />

I have not tried this yet in c5 but this seems to be a recommendation
janeyee replied on at Permalink Reply
I am not a php person, this seems to be a good solution for responsive images, but does anyone know how to make it work on Concrete theme?
mesuva replied on at Permalink Reply
Yep, I really like this kind of transparent approach - catching requests for images and delivering resized versions for different devices.

Although nearly all of the sites we are building at the moment are responsive (using Skeleton by the way), actually serving lower file size images to mobiles is on my broader TODO list.

The approach in particular i'm planning to try out is:
The set up looks really easy to be honest.

The only thing I'd perhaps want to add is something that excludes image requests that are for things from the actual theme folder - I'd be managing that via styles anyway, so I'd only want on page images like slideshows, etc, to be dynamically resized.
admin replied on at Permalink Reply
There's been some talk about adapting the image helper to serve optimized assets based on the viewport:

Definitely would be a cool project/add on for someone to make and maintain. I quickly tried dropping in the solution into a test site and, as far as I could tell, it didn't work out of the box (but that was some time ago).
clovisusd replied on at Permalink Reply
Responsive web design is no different in Concrete5 than any other CMS. All the rules lie within your stylesheet rules that you create. It's just CSS and HTML.

As far as making a theme responsive, that's a matter of creating rules based on media queries.

There are different options for making images appear at different sizes based on resolution. Again, these are media query rules.

There's also a generic way of creating graphics that scale down (although they distort but it works) and that CSS rule is:

img {max-width: 100%; height: auto;}

Best of luck.
mesuva replied on at Permalink Reply
You're right about all that, but unfortunately it's not just about considering CSS and HTML.

CSS is able to tell browsers to resize images to fit mobile designs, but it's still going be sent the full sizes image. The problem is when you're unnecessarily sending large images to a mobile device where bandwidth is limited and browsing can be slow at the best of times. It's better to serve to mobiles pre-resized images, only as large as they need to be.

That's what the original question was about - how to serve up _different_ image files for different resolutions.
clovisusd replied on at Permalink Reply
I disagree. It is all just CSS rules based on media queries. Let me give the OP an example.

This is how you would have 3 different sized headers, all based on CSS rules. You'll notice that there is not a media query for 801px and above because it will automatically use the "large screen rules" but you can otherwise see how the rules utilize media queries based on screen width. In this case, you won't have to worry about serving up images too large because you've already specified the file based on screen width. So, while my above example will scale images, this example below specifies images to change based on the media queries.

/* Rules Sensitive to Screen Size */
/* Large Screen Rules */
.page header {background-image: url(/images/header-bg-large.png);}
/* Small Screen Rules */
@media screen and (min-width: 150px) and (max-width: 500px) {   
.page header {background-image: url(/images/header-bg-small.png);}
/* Medium Screen Rules */
@media screen and (min-width: 501px) and (max-width: 800px) {
.page header {background-image: url(/images/header-bg-med.png);}   
mesuva replied on at Permalink Reply
Yes, that works great for images that are called in via CSS, images that are part of a theme.

But you're forgetting about the images that are included via the HTML itself, using IMG tags.

Examples would be a photo gallery or the use of an image block.

If a client logs in, adds a large, full width, image to a page, it could be 150kb or more. This image is going to be served to all devices, and all my css could do is physically resize the image, NOT swap it over for a version with a more mobile appropriate filesize.
mhawke replied on at Permalink Reply
@mesuva... Have you had any luck using you mentioned earlier. I added it to a test site of mine and it seemed to work well. The first time the site is viewed on a smaller screen, it dynamically creates smaller versions of your existing images and stores these images in separate folders to be served up the next time someone requests them with a small screen size. It seems to work well.

What it doesn't do is dynamically re-size screen images as you shrink the size of your browser but I'm sure someone smarter than I could bind it to a resize event.
frz replied on at Permalink Reply
If you're using the image block, with some coding you should be able to
generate and serve up different sizes as needed.

The images inline in TinyMCE you're going to have more of a challenge with

best wishes

Franz Maruna
mesuva replied on at Permalink Reply
I haven't had a chance to test it out yet, but I'm excited to hear that it's worked well for you. I'll probably give it a shot today.

With the resizing thing, I don't believe the script works on the available viewport (how big your browser is), I think it is actually works on what javascript returns as your screen resolution. The JS that sets the cookie uses screen.width and screen.height, which are screen sizes.

So it's really about returning images that match capabilities of the device. So on a desktop, even if I've resized the browser to mobile widths, it's still going to respond with a desktop version of the image. (I could be wrong about this)

The only exception I see to this is when you have a phone or a tablet and you change orientation. This might be a case of just playing with the breakpoint settings and not resizing images too small. (not setting a 320 breakpoint, just 480 for example)

One thing that I noticed that the site also has notes about excluding directories ( , on the right hand side under .htaccess).

If I've read this correctly, it means we can drop into the .htaccess file a line to limit the resizing to files in the actual /files directory (i.e. user uploaded content):

RewriteCond %{REQUEST_URI} files

Then this isn't going to try to resize theme and concrete related image resources.
mnakalay replied on at Permalink Reply
You are absolutely right for the screen size, resizing the browser window won't do anything.

Rotating your device also won't do anything. I am not sure whether handheld devices publicize their screen width to be the standing up position width whatever the rotation is or not but I think that's the idea.
mhawke replied on at Permalink Reply
clovisusd replied on at Permalink Reply
Sorry about that, I misunderstood your question.

The simple answer is that when a client wishes to add photos or media to their responsive website, I find it easier to just shoot myself in the head. Less painful that way.
admin replied on at Permalink Reply
Quote of the day right there. Totally awesome (and, so often sadly, spot on).
mnakalay replied on at Permalink Reply
I've been using on a website ( for 3 months now and it works pretty well.

Check on the Home page or the Photographs page. Works quite well on ios, only ok on android but that's a fancybox, not an adaptive image problem.
Responsive replied on at Permalink Reply
Just tested the adaptive images, in Chrome I can see the reduction on the image but not in firefox using firebug. Does anyone else have this or am I reading it wrong.