I don't know about you but I'm itching to get started with a responsive web design! Now we understand the principles of media queries, let's test drive them and see how they work in practice. And I have just the project we can test them on. Indulge me a brief digression…
I like films. However, I commonly find myself disagreeing with others (perhaps that is a contributing factor of me spending my days writing code… alone!), specifically about what is and what isn't a good film. When the Oscar nominees are announced I often have a strong feeling of revulsion in the pit of my stomach. I can't help feeling that different films should be picking up the accolades. I'd like to launch a small site called And the winner isn't…, which you'll be able to view online at http://www.andthewinnerisnt.com/ on the Web. It will celebrate the films that should have won, berate the ones that did (and shouldn't have) and have video clips, quotes, images, and quizzes thrown in to illustrate I'm correct (I know, I shouldn't need to but I'm good like that).
Much like the graphic designers whom I previously scolded for not considering differing viewports, I started a graphical mockup based around a fixed, 960 pixel-wide grid. In reality, although theoretically it would always be best to start a design thinking about the mobile/small screen experience and building up from there, it's going to be some years until everyone understands the benefits of that thinking. Until then, it's likely you'll need to take existing desktop designs and "retro-fit" them to work responsively. As this is the scenario we are likely to find ourselves in for the foreseeable future, we will begin our process with a fixed-width design of our own. The following screenshot shows what the unfinished fixed-width mockup looks like:
Breaking it down, it has a very simple and common structure—header, navigation, sidebar, content, and footer. Hopefully, this is typical of the kind of structure you're asked to build week in and week out.
In Chapter 4, HTML5 for Responsive Designs, I'll tell you why you should be using HTML5 for your markup. However, I'm going to let this slide for now, as we're so eager to test our new media queries skills. So, let's take our first stab at using media queries using good ol' HTML 4 markup. Without the actual content, the basic structure in HTML 4 markup looks like the following code:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>And the winner isn't</title>
<link href="css/main.css" rel="stylesheet" type="text/css" />
</head>
<body>
<div id="wrapper">
<!-- the header and navigation -->
<div id="header">
<div id="navigation">
<ul>
<li><a href="#">navigation1</a></li>
<li><a href="#">navigation2</a></li>
</ul>
</div>
</div>
<!-- the sidebar -->
<div id="sidebar">
<p>here is the sidebar</p>
</div>
<!-- the content -->
<div id="content">
<p>here is the content</p>
</div>
<!-- the footer -->
<div id="footer">
<p>Here is the footer</p>
</div>
</div>
</body>
</html>Looking at the design file in Photoshop, we can see that the header and footer are 940 pixels wide (with 10-pixels margin on either side), and the sidebar and content occupy 220 and 700 pixels, respectively, with a 10-pixel margin on either side of each.
First off, let's set up our structural blocks (header, navigation, sidebar, content, and footer) in the CSS. After inserting the "reset" styles, our super exciting (not!) CSS for the page looks as follows:
#wrapper {
margin-right: auto;
margin-left: auto;
width: 960px;
}
#header {
margin-right: 10px;
margin-left: 10px;
width: 940px;
background-color: #779307;
}
#navigation ul li {
display: inline-block;
}
#sidebar {
margin-right: 10px;
margin-left: 10px;
float: left;
background-color: #fe9c00;
width: 220px;
}
#content {
margin-right: 10px;
float: right;
margin-left: 10px;
width: 700px;
background-color: #dedede;
}
#footer {
margin-right: 10px;
margin-left: 10px;
clear: both;
background-color: #663300;
width: 940px;
}To illustrate how the structure works, besides adding the additional content (sans images) I've also added a background color to each structural section.
Note
Just in case you missed the memo, "reset" styles are a bunch of cover-all CSS declarations that reset the various default styles that different browsers render HTML elements with. They are added to the beginning of the main stylesheet in an attempt to reset each browser's own styles to a level playing field so that styles added afterwards in the stylesheet have the same effect across different browsers. There is no "perfect" set of reset styles and most developers have their own variation on the theme. The reset styles I use in HTML 4 documents are a combination of Eric Meyer's original (http://meyerweb.com/eric/tools/css/reset/) and a bunch of personal preferences and tricks I have picked up from studying the code of other incredibly clever folks such as Dan Cederholm (http://simplebits.com). If you don't currently use reset styles, inserting Eric's reset styles at the start of your HTML 4 document will be a good first step. I feel there are better starting points for HTML5 documents, such as normalize.css (http://necolas.github.com/normalize.css/) and we'll look at that in Chapter 4, HTML5 for Responsive Designs.
In a browser with a viewport larger than 960 pixels, the following screenshot shows how the basic structure looks:
There are numerous other ways the same kind of fixed left/right content structure could be achieved with CSS; you'll no doubt have your own preference. What's universally true of them all however is that as the viewport decreases to less than 960 pixels, areas of the content at the right start getting clipped.
For the sake of illustrating the problems with the code structure as it is, I've gone ahead and added some of the aesthetic styling from our graphic file into the CSS. As this will ultimately be a responsive design, I've been sure to slice up the background images in the most economical way. For example, for the bunting flags at the top and bottom of the design, instead of creating one long strip as a graphic file, I have sliced around two flags. This slice will then be repeated horizontally as a background image across the viewport to give the illusion of one long strip (no matter how wide things get). In real terms, this makes a difference of 16 KB (the full 960 pixels wide strip was a 20 KB .png file whilst the slice was only 4 KB) on each strip. A mobile user viewing the site over a phone network will appreciate that economy! The following screenshot shows what the slice looks like (zoomed to 600 percent) before export:
With the background images in place and basic font sizes in place, here is how the And the winner isn't… site looks in a browser window:
Style wise, there is still a lot of work to do. For example, the navigation menu doesn't alternate between red and black, the main THESE SHOULD HAVE WON button in the content area and the full info buttons from the sidebar are missing and the fonts are all a far cry from the ones shown in the graphic file. However, all these things are fixable with HTML5 and CSS3. Using HTML5 and CSS3 to solve these problems, rather than merely inserting image files (as we may have done previously), will make a website in tune with our responsive goal. Remember that we want our code and data overheads as lean as possible to afford users with limited bandwidth speeds an enjoyable experience.
For now, let's put aside the aesthetic problems and keep focused on the fact than when the viewport is reduced below 960 pixels, there is some seriously nasty clipping on our work in progress home page:
We've only reduced it to 673 pixels wide; imagine how bad it must look on something like an iPhone 3GS? That only has a 320 x 480 pixel display. Just take a look at the following screenshot:
Oh, hang on, this is embarrassing, as it looks just fine, well kind of… Of course, the iOS Safari browser automatically draws pages onto a 980 pixel wide canvas and then squeezes that canvas down to fit the viewport area. We still have to zoom in to see areas but there's no content being clipped. How do we stop Safari and other mobile browsers from doing this?