Responsive Web Design with HTML5 and CSS3: Web pages that respond immediately to different screen sizes and devices is one of today's essentials. Packed with screenshots and examples, this book will teach you the professional approach using just HTML5 and CSS3.

Internet Explorer users should make sure that they have the Microsoft Internet Explorer Developer Toolbar . This can be downloaded from the following URL:

http://www.microsoft.com/download/en/details.aspx?id=18359

If you are using Safari, my personal favorite is Resize (http://resizeSafari.com/),ERROR PARSING ATTRIBUTE CONTENTalthough ResizeMe (http://web.me.com/aaronholla/Safari_Extensions/ResizeMe.html) is similar and free.

If you use Firefox, there is Firesizer (https://addons.mozilla.org/en-US/firefox/addon/firesizer/) and Chrome users should check out the aptly titled Windows Resizer (https://chrome.google.com/webstore/detail/kkelicaakdanhinjdeammmilcgefonfh).

Not a fan of extensions? Here's a further alternative: I wrote a simple HTML page to display the current viewport height and width of a browser window. Using a dab of the JavaScript library, jQuery (http://jquery.com), this page gets the current viewport height and width, and displays them. You can keep this page open in another browser tab, resize your window, and then flick back to the website in question to see how it fares. You can find the super simple "What size is my viewport page?" page at the following URL:

http://benfrain.com/easily-display-the-viewport-size-of-your-page-for-responsive-designs/

Now, we're armed with everything we need to start appreciating the best that the responsive web has to offer. Fire up your browser of choice, engage your screen size tool, and take a look at http://thinkvitamin.com/.

If you are viewing the page with a viewport larger than 1060 pixel wide, you will see a layout similar to the one shown in the following screenshot:

If however, you're viewing the site with a viewport larger than 930 pixels but lower than 1060 pixels, you will see a layout, as shown in the following screenshot:

Notice how the main navigation to the side of the logo has changed? The icons to the right of the main content have been arranged to sit one under another. Everything is perfectly usable, and most importantly, isn't disappearing off the screen. Now, take a look with a viewport less than 880 pixels, in the following screenshot:

The header remains similar but notice that the right-hand sidebar is thinner still; the icons are now 2 by 2 whilst the text blocks have adjusted and the text is flowing accordingly within the block.

However, reduce your viewport to less than 600 pixel in width and you will notice a major change, as shown in the following screenshot:

How about that? The entire sidebar has responded to our new viewport, letting the most important part of the site, the content, enjoy the full width of the browser window. Notice also how the header links are now horizontal, as opposed to being at the side of the logo, and the logo itself has resized? All these changes help to create a better experience for the user based upon the viewport dimensions.

Let's look at another example, http://2011.dconstruct.org/. With a wide viewport (say, more than 1350 pixels) the site looks like the one shown in the following screenshot:

Notice particularly the grid of nine images. As you decrease the width of the viewport (to less than around 960 pixels), notice what happens? The grid of three rows of three images becomes three rows of two images and one row of three at the bottom, as shown in the following screenshot:

Decreasing the width of our viewport smaller still, at less than around 720 pixels we encounter another design "break point"; the header links switch to include images that provide a better target area for touchscreen navigation:

Smaller still, once we reduce the viewport to less than 480 pixels wide, the image grid changes again, now showing a row of two images, then three, and then four. These images continue to resize as the viewport is shrunk to around 300 pixels. To illustrate, the following screenshot shows how it looks on an iPhone:

One web destination that is useful for inspiration is http://mediaqueri.es. However, not all websites displayed there necessarily embrace the full responsive methodology of displaying content around small viewports first, and progressively enhancing for larger viewports. Regardless, at this early point, whilst considering the possibilities of what we can do with responsive web design, there are many great examples to draw ideas from. Although viewing these websites and resizing the viewport illustrates what a responsive web design can do, it doesn't demonstrate what's good about HTML5. The benefits of HTML5 occur "behind the scenes" as it were, so let's now turn our attention there and find out what's so great about HTML5.

The first line of any HTML document starts with the Doctype (Document Type Declaration) . This is the part that, if we are honest, gets added automatically by our code editor of choice or we can paste it from an existing boilerplate (nobody really enters the full HTML 4.01 Doctype out, do they?) Before HTML5, the Doctype for a standard HTML 4.01 page would have looked as follows:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

Now, with HTML5, it's merely as follows:

<!DOCTYPE html>

Now, as I've already conceded, I don't physically type the Doctype every time I write a page, and I suspect you don't either. So, what's the big deal I hear you cry? Well, what about adding links to JavaScript or CSS in your pages? With existing HTML 4.01, the correct way of linking to a script file would be as follows:

<script src="js/jquery-1.6.2.js" type="text/javascript"></script>

HTML5 makes this easier:

<script src="js/jquery-1.6.2.js"></script>

As you can see, the need to specify the type attribute is no longer considered necessary. It's a similar case with linking to CSS files. HTML5 also accepts a far slacker syntax to be considered "valid". For example, <sCRipt SrC=js/jquery-1.6.2.js></script> is just as valid as the prior example. We've omitted the quotation marks around the script source as well as using a combination of upper and lower case characters in the tag and attribute names. But HTML5 doesn't care—it will still validate at the W3C HTML5 validator (http://validator.w3.org/). This is good news if you are sloppy with your code writing but also, more usefully, if you want to shave every possible surplus character from your markup. There are other specifics when it comes to the writing of code that make life easier. But I'm guessing you're not convinced this is all that exciting. So, let's take a quick peek at the new semantic elements of HTML5.

When you're structuring an HTML page, it's standard fare to mark up a header and navigation section something like this:

<div class="header">
  <div class="navigation">
    <ul class="nav-list">
      <li><a href="#" title="Home">Home</a></li>
      <li><a href="#" title="About">About</a></li>
    </ul>
  </div> <!—end of navigation -->
</div> <!—end of header -->

However, take a look at how we do it with HTML5:

<header>
  <nav>
      <ul id="nav-list">
        <li><a href="#" title="Home">Home</a></li>
        <li><a href="#" title="About">About</a></li>
      </ul>
  </nav>
</header>

How about that? Instead of faceless <div> tags for every structural element (albeit with added class names for styling purposes), HTML5 gives us some far more semantically meaningful elements to use instead. Common structural sections within pages such as header and navigation (and many more as we shall soon see) get their own element tags. Our code just became far more "semantic" with the <nav> tag telling browsers, "Hey, this section right here is for navigation". Good news for us but perhaps more importantly, good news for search engines, too. They'll now be able to understand our pages better than ever before and rank our content accordingly.

When I write HTML pages, I often do so knowing that they will in turn be passed to the backend crew (you know, those cool kids that deal with PHP, Ruby, .NET, ColdFusion, and so on) before the pages ultimately make it to the WWW. To stay on good terms with the backend folks, I often comment the closing </div> tags within the code to enable others (and often myself too) to easily establish where <div> elements end. HTML5 negates much of that task. When looking at HTML5 code, a closing element tag of </header> for example, instantly tells you what element is closing, without the need to add a comment.

We're just lifting the lid a little here on what semantic goodies HTML5 has for us in the toy box. Before we get carried away, we have one more friend to get acquainted with. If there's one thing this whole new era of web design can't exist without, it's CSS3.

Perhaps the most empowering point of note is that there is no penalty in older browsers for including properties that they do not understand. Older browsers (including Internet Explorer 6, 7, and 8) will happily skip over CSS3 properties that they can't process. This gives us the ability to progressively enhance areas of a design for the better-equipped browsers, whilst ensuring a reasonable fall back for the older ones.

Let's consider a common design hurdle we all face on most projects—to create a rounded corner on a screen element, perhaps for a tabbed interface or corner of a boxed element such as a header for example. Using CSS 2.1 this could be achieved by using a sliding doors technique (http://www.alistapart.com/articles/slidingdoors/), whereby one background image sits behind another. The HTML could look as simple as this:

<a href="#"><span>Box Title</span></a>

We add a rounded background to the <a> element by creating two images. The first, called headerLeft.png , would be 15 pixels wide and 40 pixels high and the second, called headerRight.png in this example, would be made wider than we would ever anticipate the header being (280 pixels, here). Each would be one half of the "sliding door". As one element grows (the text within our <span> tags), the background fills the space creating a somewhat future proof rounded corner solution. Here is how the CSS in this example looks:

a {
  display: block;
  height: 40px;
  float: left;
  font-size: 1.2em;
  padding-right: 0.8em;
  background: url(images/headerRight.png) no-repeat scroll top right;
}
a span {
  background: url(images/headerLeft.png) no-repeat;
  display: block;
  line-height: 40px;
  padding-left: 0.8em;
}

The following screenshot shows how it looks in Google's Chrome (v16):

It solves the design problem but requires additional markup (semantically the <span> element has no value) and two additional HTTP requests (for the images) to the server to create the onscreen effect. Now, we could combine the two images into one to create a sprite and then use the background-position: CSS property to shift it around but even with the bandwidth economies that provides, it's still an inflexible solution. What happens if the client decides they want the corners to have a tighter radius? Or a different color? We'd need to re-make our image(s) again. Sadly, until CSS3, this has been the reality of the situation we, as frontend designers and developers have found ourselves in. Ladies and gentleman, I've seen the future, and it's CSS3 shaped! Let's revise the HTML to be only:

<a href="#">Box Title</a>

And, to begin with, the CSS can become the following:

a {
  float: left;
  height: 40px;
  line-height: 40px;
  padding-left: 0.8em;
  padding-right: 0.8em; 
  border-top-left-radius: 8px;
  border-top-right-radius: 8px;
  background-image: url(images/headerTiny.png);
  background-repeat: repeat-x;
}

The following screenshot shows how the CSS3 version of the button looks in the same browser (Chrome v16):

In this example, the two previous images have been substituted for a single 1 pixel-wide image that is repeated along the x-axis. Although the image is only 1 pixel wide, it is 40 pixels high, hopefully higher than any contents that will be inserted. When using an image as a background, it's always necessary to "overshoot" the height, in anticipation of content overflowing, which sadly makes for bigger images and greater bandwidth requirements. Here, however, unlike the entirely image-based solution, CSS3 takes care of the corners for us with the border-radius and related properties. Client wants the corners to be a little rounder, say 12 pixels? No problem, just amend the border-radius property to 12px and your work is done. The CSS3 rounded corners property is fast, flexible, and supported in Safari (v3+), Firefox (v1+), Opera (v10.5+), Chrome (v3+), and Internet Explorer 9. Microsoft are so excited about IE 9's support of the feature that (I hope you feel my slight sarcasm seeping through here) they have even designed an interactive page demonstrating the various effects that can be achieved with the border-radius property . View this demonstration at the following URL:

http://ie.microsoft.com/testdrive/html5/borderradius/default.html

CSS3 can take things further by eliminating the need for a gradient background image by producing the effect in the browser instead. This property isn't as well supported but with something along the lines of linear-gradient(yellow, blue), the background of any element can enjoy a CSS3 generated gradient.

The gradient can be specified in solid colors, traditional HEX values (for example, #BFBFBF) or using one of the CSS3 color modes (more on these in Chapter 5, CSS3: Selectors, Typography, and Color Modes). If you're happy for users of older browsers to see a solid background instead of a gradient (as opposed to nothing), a CSS stack something like this would provide a solid color in the event of the browser being unable to handle the gradient:

background-color: #42c264;  
background-image: -webkit-linear-gradient(#4fec50, #42c264);
background-image: -moz-linear-gradient(#4fec50, #42c264);
background-image: -o-linear-gradient(#4fec50, #42c264);
background-image: -ms-linear-gradient(#4fec50, #42c264);
background-image: -chrome-linear-gradient(#4fec50, #42c264);
background-image: linear-gradient(#4fec50, #42c264);

The linear-gradient property instructs the browser to start with the first color value (#4fec50, in this example) and move to the second color value (#42c264).

You'll notice that in the CSS code, the background-image linear-gradient property has been repeated with a number of prefixes; for example, -webkit-. This allows different browser vendors (for example, -moz- for Mozilla Firefox, -ms- for Microsoft Internet Explorer, and so on) to experiment with their own implementation of the new CSS3 properties before introducing the finished article, at which point the prefixes are unneeded. As stylesheets by their nature cascade, we place the un-prefixed version last, meaning it will supersede the earlier declarations if available.

So far, we've looked at a very mundane example of where CSS3 can help in everyday development tasks. However, let's whet our appetite a little and see what real treats CSS3 allows us. Fire up Safari or Chrome and take a look at http://www.panic.com/blog/. Whilst sadly this design isn't responsive, the area of interest for us are the pinned notes at the top. Hover over them and watch as they float out. Nice, eh? In the past this kind of enhancement would have been the domain of resource heavy Flash or JavaScript. Here, it is being achieved entirely through CSS3 transformations. Using CSS3 rather than JavaScript or Flash makes the animation lightweight, maintainable, and therefore perfect for a responsive design. The browsers that support the feature get it, whilst others are none the wiser, merely seeing a static image in its place.

Another great example of CSS3 transformations is http://demo.marcofolio.net/3d_animation_css3/. Again, this isn't a responsive web design, we're just looking at the CSS tricks being employed. Take a look at this in Internet Explorer 9 or Firefox first (as of version 9.0, Firefox still didn't support the necessary CSS3 module). Now, take a look in Safari 5+ or Chrome 16+. The following screenshot doesn't do it much justice so if you're not going to take a look you'll have to take my word for it—it's good:

But great looking effects aren't solely the domain of the Webkit-based Safari and Chrome browsers. The following URL works in Firefox too and is another pure CSS3-based solution:

http://designlovr.com/examples/dynamic_stack_of_index_cards/

Obviously, these effects are not essential for any website. They are a perfect illustration of "progressive enhancement". In browsers that do not support the effects, they merely see the static images. However, users with more modern browsers can enjoy the visual enhancements. Whilst browser support for CSS3 3D Transformations is rather limited, support for CSS3 rules such as text-shadows, gradients, rounded borders, RGBA color, and multiple background images are all widely supported and provide flexible ways of providing solutions to common design problems that have had us all cursing and scratching our heads for years.