5/8/13
By Emily P. Lewis
If you haven’t been living under a rock for the past year or so, you know that responsive Web design is one of the biggest trends these days. Introduced by Ethan Marcotte, the concept is simple: develop a site using methods that enable it to adapt and respond to different devices and resolutions.
When I first learned of this, I was instantly intrigued — particularly with the notion of using media queries, which I immediately applied to my own freelance site. I even wrote an article about the process: “Respond to Different Devices with CSS3 Media Queries.” (I strongly encourage you to read that article before delving further into this one. Go ahead. I’ll wait.)
As a result of my first media queries endeavor, I quickly realized I was missing a key part of the responsive design equation: flexibility.
Challenges with Fixed Widths
My freelance site is a fixed-width design, meaning all the width, margin and padding settings are specified in pixels. Traditionally, this has been my preference when building sites because it’s easier and faster for me.
But when writing the media queries for my fixed-width site, those easier and faster aspects rapidly disappeared. Why? Because with a fixed-width design, I found that I needed extremely detailed and verbose media queries to adjust for every single pixel value in my CSS. I was basically creating an entirely new layout for every potential resolution. Not easy. Not fast. Not fun.
Then I had the pleasure of listening to Mr. Marcotte speak at In Control 2011. He discussed responsive design as a theory and then dove into practicalities, like the fluid grid.
A Fluid and Flexible Formula
Fluid layouts are flexible. They resize with the browser window because width, margin and padding elements (even fonts and images) are specified with proportional values like percentages and ems. As the resolution changes, the layout adjusts proportionally. And all without a single media query.
This was when I had my “ah ha” moment for responsive design. If I had a layout based on proportional values, the fluid grid would do much of the heavy lifting I needed. My media queries wouldn’t have to include styles to, essentially, overwrite all of my width, margin and paddingvalues.
At the same time, I had an “uh oh” moment. Fluid grids require math to determine those proportional values. And I suck at math.
Fortunately, Ethan offered a formula for implementing fluid grids that looked simple enough (even for me):
target ÷ context = result
This formula takes the pixel-based width of an element on a page (the target) and divides it by the pixel-based width of its parent element (thecontext). The result becomes the proportional width for the target element.
Figure 1 Example of Target (300px) and Context (960px)
In Figure 1, for example, one of the dark gray containers is 300 pixels wide and is contained in the 960-pixel light gray container. Here, the 960-pixel container is the context and the 300-pixel container is the target. And so our mathematical formula is:
Logo: 240 ÷ 940 = .255319148
Hosts: 436 ÷ 940 = .463829787
Social media links: 90 ÷ 940 = .09574468
I then translated each of these values to percentages, which I used in my CSS declarations.
Putting It to the Test
Though the formula seemed simple, I knew I had to apply it to a real-world site to know for certain. Fortunately, I’d recently joined the EE Podcast, and we were redesigning the site. When my cohost handed me her Photoshop comps, I made the commitment to develop the site with a flexible layout.
Proportional Widths
I began by documenting the widths for all my elements. (We didn’t follow a strict grid in the comp design, which I would recommend). As you can see in Figure 2, the main container for the header is 940 pixels, while the logo, hosts and social media links have their own pixel widths.
Figure 2 Pixel Widths for the Main Page and Header Elements
To determine the percentage values for the elements within the header, I followed Ethan’s formula, with the full header width of 940 pixels as my context.
Logo: 240 ÷ 940 = .255319148
Hosts: 436 ÷ 940 = .463829787
Social media links: 90 ÷ 940 = .09574468
Note that for all these values, I never round up the percentages. The exact value from the calculation needs to be used in the CSS. I didn’t have a single issue with these long percentages with any browser (including Internet Explorer).
Also note that after each of my percentage values I included comments that show the original pixel value (target) and context value, which is an invaluable development reference.
Get Your Context Right
The process of converting widthvalues to percentages is straightforward … as long as your math is correct. Or, more specifically, as long as you are referencing the correct context.
In a handful of situations, my calculations didn’t result in a percentage that displayed correctly. Every single time, this happened because I used the incorrect context value in the formula.
As Figure 3 suggests, the hosts information is a definition list (
- ) containing elements (
- ,
- , , etc.) of varying widths.
Figure 3 Pixel Widths for the- width, I calculated:
116 ÷ 960 = .120833333
Yet the resulting percentage (12.0833333%) didn’t deliver the dimensions I needed. Not until I realized that my context was different did I get the correct percentage values.
For the
- , the context is actually the parent
- from the hosts information (Figure 3), which has a right margin of 20 pixels. To get a percentage value for this margin, I use the same formula as for width:
20 ÷ 436 = .04587159
For padding, it is the same.
Figure 4 Horizontal Padding for Main ContainersA Special Exception
The formula for horizontal padding offers one special exception: the context is always the width of the element itself, regardless of the parent width.
For example, the social media links in the header (Figure 5) all have left padding of 25 pixels to allow for the display of icons.
Figure 5 Context for PaddingThe calculation to get a proportional value for this padding references only the element’s width (90px) for context, even though the parent element is 940px (Figure 2).
25 ÷ 90 = .277777777
This gives me the following percentage for my CSS padding:
#push li a {
padding-left: 27.7777777%; /* 25px / 90px */
}
Vertical Values
So far, we’ve dealt strictly with horizontal values—that is, left and right. However, with padding and margins you may be specifying values for both the x and y axes, which means your contexts change depending on whether you specify horizontal or vertical values.
As you’ve seen with all the calculations thus far, horizontal percentage values have a context of the parent width (padding being the exception). Vertical em values, meanwhile, have a context of the baseline font.
If you recall from the proportional font calculations, the baseline font for ee-podcast.com is 16px. So, if I want to specify vertical margin or padding, I use 16px as my context. Additionally, vertical values are specified in ems, not percentages — just like proportional font values.
The
and
When I initially did my calculations, I used the 960-pixel header (see Figure 2) as my context. So, for the
- , which is 436 pixels. This changed my calculation and gave me the percentage I needed:
116 ÷ 436 = .266055045
If you have problems with your percentage values, first check that you have the correct context value. You’ll save yourself headaches and time.
Proportional Fonts
The next step I took in making ee-podcast.com flexible was to use proportional fonts. This is essentially the same concept as proportional widths: instead of fixed pixel values, use a proportional value. With fonts, the proportional value of choice is ems.
The baseline font for most modern browsers is 16 pixels, so if you use the example above, where font size is 100%, your context for font sizes is 16px.
Proportional Padding and Margins
When it comes to padding and margins, the magical formula remains the same. Let’s consider the
- width, I calculated:
