The Theory

Simply put, Responsive Web Design combines the idea of a fluid site layout- one that contracts and expands with the browser width- with the technique of using CSS media queries to detect the browser widths and change the style, layout and proportions of your website content so that users enjoy a seamless experience, regardless of whether they are using a smartphone, tablet or widescreen desktop monitor to view the site.

As I work almost exclusively with Drupal and WordPress themes, I wanted to see how well this translated to a CMS environment, where you have contributed plugins and modules that use their own markup and CSS in addition to the theme.

Starting with the fluid grid

Our project at hand was a Drupal site, a simple brochure-style arrangement. The most complex features of the site include an automated pager slideshow that moves in tandem with testimonial quotes, a multi-page form and a photo gallery, so it seemed like a pretty clean example to use. The custom theme we had built utilizes HTML5 markup and the 960 grid system was in place, so my first step was to convert a fixed, pixel-width grid with one that uses percentages.

Now, when you calculate your percentage widths, it is important to remember that this is a percentage of the containing element, which in most cases is going to be 960px, or 100%. It is pretty simple to convert the 960 CSS to percentages assuming 960=100%.

However there are times when your grids are nested in containers that are already percentages of 100%. This is actually really common in a CMS environment where you have templates within templates. This issue is what I will call:

Pitfall no.1: Nested grid classes

Very important to check all pages and processes in your new fluid grid, as you will undoubtedly find the need to override grid-widths for elements in a container of less than 100%.

Text and Font sizes

After the width issues were sorted out, time to focus on the text. Rather than using fixed pixel font sizes, which can be tempting, proportional font sizes based on ems will flex with the fluid grid. As Ethan Marcotte points out, most browser defaults font size to 16px, so calculating ems based on a 16px = 100% generally yields good results.

Pitfall no.2: Multiple text CSS designations

In the CMS environment, there are multiple stylesheets. This is an understatement. There will be stylesheets in the system that affect CMS core processes that hardly seem styled, there will be stylesheets for core and contributed plugins and modules, and there are stylesheets in the theme that you are building on top of stylesheets in any other enabled theme that affect your site.

My point is, you might find that one of these stylesheets has already set font-size to 62.5%. So your em calculations, though you think they are a percentage of 16 pixels, are really a percentage of a percentage of 16 pixels.

Rather than do anything more complicated than division of whole numbers via calculator, I found it important to reset my body font-size to 100%, and restore predictability to the browser display of my text.

Contributed code

I don’t think I have ever completed a CMS website without using contributed modules or plugins. This introduces more complexity in your responsive theme.

Pitfall no.3: Markup and styling beyond your direct control

Many contributed features come with their own markup, templating and CSS. You may find in your perfectly fluid theme that there is an element that is not re-sizing. Time spent finding and overriding contributed styling is time well spent for a seamless user experience. You may find however, that there is no override that you can implement that will work in the way you’d like. For instance, in my project, we had the slideshow with image pagers and testimonial quotes. This piece, though overridden in the CSS with flexible proportions, does not change on the fly as you resize your browser; you need to reload your page and then the content will resize itself to fit. As there was no room in the budget to re-develop the module to accommodate the behavior, we had to let this one stay.

Image Handling

Oh boy. OK. So if you set your images to have a max-width of 100% and a height of auto (yes, do add the !important to the height, it’ll work better), it should result in magically resizing images that stay in proportion through your browser resizing exercise. Hooray we’re done!

Ok hold it, we’re not done. In the world of the CMS you are usually working with additional image handlers that allow you to create size presets so that your clients do not have to be photoshop experts to get a good looking, perfectly sized image into their content.

Pitfall no.4: Content Image handling

In my example, I am going to use a Drupal 6.x site with Imagecache as my example. Imagecache size presets use either pixels or percentages, so this seems to be a pretty clear case of just using the percentages directly in your presets. However! Percentage widths in CSS calculate the percentage of the width of the containing element. Percentage widths in Imagecache calculate the percentage of the original image size. Instead of easily controlling the proportion of the image, this effectively does the opposite. Yes, you can say that only images of a certain pixel width can be uploaded, but we are using the presets to circumvent the need for such a requirement.

In this case, I found it necessary to retain pixel width presets. This turns out to be okay because we are overriding the widths in our CSS img max-width setting. I still noticed a difference in the content images however: the photo gallery thumbnails were resizing on the fly, as the browser changed widths, as expected. The inline content images that were inserted into page text via the WYSIWYG editor were not changing proportions on the fly. They retained their preset pixel widths while the size of the paragraphs and sidebars changed around them.

Here is why:

The photo gallery thumbnails, though they as well had pixel width presets, were wrapped in containing divs that had percentage widths. Their containers were resizing proportionally and since they wrapped the images tightly, were forcing the images to resize as well. The max-width 100% at work! The inline content images by contrast, were not wrapped with a special container. They were simply image tags inserted in a larger content div with paragraphs wrapping around them. Because max-width 100% specifies images to be no wider than their container, the inline images keep their pixel widths until the container becomes smaller than the pixel width. Then they resize proportionally.

A workaround

In case this is not acceptable to you, there is a CSS workaround you can implement to force the WYSIWYG images to resize like the div-wrapped images. If you are working with Imagecache, you’ll find that it inserts classes for your presets: imagecache-small, imagecache-medium, etc. Depending on your WYSIWYG setup you may need to manually configure these classes to be inserted. Once you have these classes available to you, you can create CSS percentage widths that override the preset pixel widths.

This works great, but does add a few more steps. If someone other than you will be adding or editing presets in the future, this becomes a less flexible solution. I would be happy to hear of an alternate, less time-consuming, more flexible way to deal with this issue in case you have come up with one.

Pitfall no.5: Background image handling

Oh, you didn’t think there was only one image handling pitfall, did you? The background image pitfall is simple: images set in the CSS as background do not resize. Depending on your design, this may not be an issue at all. Hooray! I will give an example of where this might be an issue: UI icons such as the little pager button images in our slideshow or arrows in a dropdown menu. The containers and text will contract and expand around them, but they remain the same size; thus appearing larger when their world gets smaller.

In the case of the pager images, I had dutifully set percentage widths for the pager containers. As the browser window collapsed and the content got smaller, the pager images appeared awkwardly cropped and had too little space between them. Rather than making differently sized images for various browser widths and switching them out at all the breakpoints, I decided to leave this particular bit in pixels, as it was the most elegant way to handle them and did not negatively affect the resulting layout.

Finishing up

We have now a flexible theme that responds to browser and device widths, resizing content and layout elements on the fly. But there is one more pitfall to overcome.

Pitfall no.6: Internet Explorer

IE 8 (and under) does not do media queries, so without extranious help from javascript, your flexible theme will flex, but the layout will not change so the small views will be squished and the very wide views will be stretched. IE also has issues with min- and max- width, so these settings will also need to be taken care of.

Depending on the target audience of your site you can “cheat” and just set fixed pixel widths for your site wrapper or spend the time to make your site elegant and responsive for Internet Explorer users as well.

Javascript help for IE: Respond.js 

Written by Scott Jehl, respond.js enables support for min- and max-width media queries in IE8 and under. One caveat for Drupal and Wordpress: the script will not work if your media query stylesheet is referenced using @import url. If your theme is including css in this way, make sure the stylesheet with the css on it is referenced using the <link> tag. For Drupal, this likely means leaving it out of your theme.info file and manually inputting the link in your html.tpl.php file (or page.tpl.php for drupal 6).

A word on testing

Responsive design makes no assumptions on the device or screen resolutions that site visitors will be using, therefore we should be even more vigilant about testing in all the browsers and platforms. Of course I am not going to say that everyone needs to have all the devices on hand; merely that testing on desktop browsers is not enough. Getting tablet and smartphone simulators for the major platforms is my suggestion. You will not be able to anticipate everything, but the more you see the better you can make the experience for an overwhelming majority of site visitors. If you know of a great device emulator, please feel free to mention it!

In sum

In my opinion, the best way to learn about Responsive Web Design is to read and follow Ethan Marcotte’s method. Adapting the practice into a CMS theme can bring up issues that a hand-coded site does not have; you may need to work a little harder to take care of multiple devices but it will raise the value of your project with increased user satisfaction and even maybe enjoyment.