Above the Fold

Remember when we first started building web sites, in the late 1990s, one of the first things that we’d do is browse the web to see if any sites would inspire us. For those web sites that awed us, we’d not only appreciate how beautiful the design was, but we’d also look at the source code to view how the designers leveraged HTML and CSS. At that time, HTML was still in its infancy, and the browser wars between Internet Explorer and Netscape Navigator were in full swing. Browser vendors were actually providing browser-specific HTML and CSS tags that swayed web designers to build sites that worked better in a specific browser versus another.

Web designers would proudly display a banner in the footer such as the once popular banner shown in Figure 2-2. This was a way to tell their visitors what browser would provide them the optimal experience.

Targeting web sites for a specific browser worked well for web designers, as they did not have to build and test for multiple browsers. But how did visitors feel when they visited a site with a banner? The banner was a constant reminder that their browser was not properly equipped. Typically, they would get a gentle reminder to upgrade their browser; worse, the site would refuse to load. Seeing such a banner on a web site could make users cringe. Why? Designers were defining what browsers we could use to browse their sites, and in a sense, the Internet as a whole. This went against everything the web was envisioned for: a universally accessible resource. Aren’t we glad that Tim Berners-Lee, inventor of the World Wide Web and director of the W3C, felt the same way?

The single most important optimization that you can do for any web site is to optimize what content they see above the fold. Figure 2-3 shows how little of the Specter Group site you would be viewing if it weren’t for the recent advances made on viewports.

Visually, the first viewable portion of any device’s browser is called the viewport. As web developers, you have the ability to define the viewport. In the past, you had to design specifically for above the fold. Apple recognized this early on and provided a metatag named Viewport as part of their release of the iPhone. With the viewport not set, it was always a problem for web sites. You missed so much of the site that usually with previous smart phones, we had to squint, zoom, and pan web sites and try to click on links for sites that were not optimized. Smart phones have come of age but web sites are still lagging.

There’s nothing wrong with optimizing for the common browsers that your visitors are using. However, for users who are still viewing your site on older browsers or mobile browsers, do the right thing and give them an alternative. It might not look as polished or as sophisticated, but as long as the site is functional, you’ve done your visitors a service. If you want to continue building a site that targets specific browsers, you are practicing browser-centric design, a slippery slope to follow.

In this chapter we investigate the general concepts of a current technique used to build both modern and stylish sites that are backward-compatible with older browsers, referred to as responsive web design. We review the origins of responsive web design and how it evolved. We’ll also have a quick look at some of the new features of HTML5, CSS3, and jQuery that make responsive web design more practical. We continue by diving into the basics of what makes a site a candidate for responsive web design and finish with a look at some of the best practices of implementing responsive web design.

Graceful Degradation

When web development started gaining popularity, web designers leveraged the functionalities the latest web technologies had to offer and showcased them in modern browsers. This was great for those visitors who had modern browsers, but visitors with older browsers were unfortunately left behind. When browsers encountered tags that they didn’t recognize or couldn’t display, the browsers would not crash. Instead the markup was ignored and the browser would do its best to display the remaining web site markup.

The concept of graceful degradation was introduced as best practice for providing the best experience to users with the latest modern browsers. For those who didn’t have a modern browser, web designers would not provide equivalents. Visitors with the latest modern browsers felt like first-class citizens and interacted with the site as web designers intended. Those without the latest web browsers were at least given a web site that degraded gracefully to a lower level of functionality.

One simple example of graceful degradation is the “alt” attribute for images. When the alt attribute is used properly, it displays a text alternative that conveys the same information as the image. Visitors who can’t view the image or have browsers that can’t display images get to see the alternate texts. Given that an image is worth a thousand words, it’s still fair to say that the text equivalent is not aesthetically pleasing, which slightly degrades the user experience.

Although in theory graceful degradation seemed to make sense, what happened in practice was that web designers built sites for those with the most modern browsers. Visitors with older browsers were left with limited or reduced functionality as the web designers did not design or code sites that would in fact degrade gracefully. In essence, graceful degradation worked as a basic measure, but in practice it did not help.

Progressive Enhancement

Progressive enhancement, on the other hand, begins with the basic version of the site to ensure that it works on all browsers. Web designers can then add enhancements specifically for modern browsers. Progressive enhancement focuses on content first rather than functionality, which is important, as content is truly the only reason any one of us browse or build web sites in the first place. As a comparison, graceful degradation prioritized presentation and functionality before content and progressive enhancement prioritized content to the top of the web designer’s priority list.

Another factor that helped push progressive enhancement as a favorable approach over graceful degradation was how quickly older browsers were not supported by web designers. More often than not, web designers were asked to support older browsers. As we know, older browser versions and browser vendors render HTML and CSS tags differently. This is a battle web designers find it hard to win, as they are always trying to achieve pixel-perfect solutions. The argument went that it didn’t make sense to be putting in twice the effort for a smaller subset of visitors who were still using older browsers. Focusing on content and ensuring that all visitors are able to view content in all browsers was a reasonable goal and any advanced functionality web designers wanted to make available could be tailored to the browsers that supported them.

The simplest example of progressive enhancement is the use of the external CSS style sheet. Modern browsers apply the external CSS style sheet to the site, whereas non-CSS browsers simply ignore it. For non-CSS browsers this means that only the content loads up and the browsers present it using built-in styles.

Progressive enhancement builds a rich experience on top of an accessible core without compromising that core. It improves on graceful degradation by prioritizing content over presentation. This is a great step forward and is still the basis of modern web design, but then mobile devices came along.

Separate Mobile Site

By the time progressive enhancement had become popular, the mobile phone revolution was gaining speed. Web designers were being sanctioned to build sites tailored for mobile devices, primarily by building separate mobile sites. They were even going so far as having separate mobile domains to tailor to mobile visitors. But it wasn’t until the iPhone was introduced in 2007 that mobile usage really started gaining speed. Mobile sites all of sudden not only became mainstream, but web designers were starting to create feature-rich separate mobile sites tailored to the iPhone. In a matter of just a few years, web designers were now being asked to ensure that their sites were viewable and functional on multiple devices.

Creating separate mobile sites and ensuring that they worked on a multitude of devices was popular for a while. However, as the sheer number of smart devices grew, this approach simply became uneconomical. Web designers now had to consider the user experience for each variation of mobile device, browser, operating system, and display resolution, and how to best take advantage of each combination. Further complicating matters, web design had to be completely reimagined for the keyboard and touch interface.

The same code base typically wasn’t used for both sites (larger and smaller devices) and because of that, development costs were higher. Web designers learned very quickly and this time around, they knew there had to be a better way. The problems faced in developing separate mobile sites ended up being the same problems web designers faced when developing sites for larger devices (i.e., different browsers on desktops).

Responsive Web Design

Progressive enhancement, graceful degradation, and separate mobile sites all have their place in a web designer’s toolbox. However, having web designers create specialized web sites for specific devices was not a favorable approach. Necessity is the mother of innovation, and web design needed a savior: Let us introduce responsive web design. Responsive web design is about developing a site from the beginning for all screen resolutions, browsers, and devices.

Responsive web design is all about building a web site that is resolution and device independent. It is an evolution of web design, rather than a revolution. Why? Primarily because the foundation of responsive web design stems from two existing web design approaches: graceful degradation and progressive enhancement. The term responsive web design was coined by Ethan Marcotte in the popular article at A List Apart, “Responsive Web Design” (http://sprwd.com/3u6qod), as an approach that popularized the use of flexible grid layouts, flexible images, and media queries into one unified methodology.

If we are to truly have a responsive methodology to web design, we should design for the smallest viewport first and then progressively enhance the design and content for larger viewports. We can create one web site that adapts based on the features available on that device as well as screen size.

Adaptive Design

Does it stop at responsive web design? Not at all. Responsive web design is just the latest design principle in ever evolving web design methodologies. Keep in mind that responsive web design is not a silver bullet and has limitations as it is based around the fluid grid. What if we still want to build tailored or semi-tailored experiences for different viewports all in one site? Web designers started looking at the principles of responsive web design and including the principle of feature detection in progressive enhancement. This has evolved into a general methodology, adaptive web design.

As a web designer, wouldn’t you want to keep an eye on your visitors and what device they are using to experience your site and how? Now that the site has been built from the ground up to leverage responsive web design based on device capabilities, browser capabilities, and browser resolution, what happens next?

Analytics and usage patterns are really the driving factor behind adaptive design. Don’t we want to know what devices, browsers, and resolutions are most popular? Which ones are the least popular? Is there a segment of the site’s visitors that have not been looked after? If so, is there a good enough reason for this? All these questions and more are important. After the site launch, there are quite a few opportunities you can take advantage of to adapt your current design; here are a few:

• Feature detection. Why not detect and apply only those features that the device and browser can handle? This is similar to progressive enhancement, but might differ because this does not only include improving the site based on available features, but possibly modifying the layout or content of the site based on the device.
• Device APIs. Take advantage of functionality device manufacturers provide via APIs to leverage device accelerometers and even functionality like near field communication (NFC) as part of the user experience that’s provided to enhance the site visitors’ experience.
• Performance. Having taken advantage of responsive web design, is there a large audience of members that need a targeted web design because of their low bandwidth? Why not consider a solution to address this for your users? This could be as simple as removing the use of images for navigation and instead using text and CSS.
• Touch optimization. Have you considered leveraging gestures to browse and interact with your web site? As more devices provide touch-focused user interface, why not have your web site take advantage of this?
• Platform optimization. One of the things you’ll quickly learn is that you can start looking at analytics to view which device and operating system combination is most popular for visitors browsing your site. Why not provide them tips to have your web site be pinned on their mobile home page? If part of the site’s marketing strategy is to provide a mobile application, why not suggest that to the visitors on their first visit.

Adaptive design and responsive web design are both paradigm shifts for many web designers to start building a single web site that tailors to different devices, browsers, and resolutions. It provides web designers the opportunity to focus on content first and then layer on functionality.

A web designer’s design process never stops. It consistently continues to improve and the expectation is that it’ll help us to keep improving our processes. As students of web design, let’s ensure that we all take an oath to keep evolving, improving, responding, and adapting our designs and in turn, enriching the experience of those visitors who use our sites.

Fluid Grid

As part of the creative design process, designers use a grid system to align and organize elements in a visually pleasing way on a particular page layout. The grid system uses a combination of margins, rows, and columns. The driving force behind leveraging a grid system in your designs is alignment. The alignment helps visitors recognize patterns and these patterns simplify designs to make them easily recognizable.

Building a grid system, in theory, is fairly easy. For instance, you start your design with a 1,000-pixel-wide container and you want to split it up into three (equally sized) columns. Each column would be one third the size of the container, or 333 1/3 pixel per column. That doesn’t exactly add up, so we add 10-pixel margins on each side of every column. This means we also must subtract the 20 pixels from the width of each column. Adding the three columns, roughly 313 pixels wide for each column, 10 pixel margins on each side and we still end up with a container 999 pixels wide, not 1,000 pixels wide. You might continue this process to splitting your design to enforce structure using grids. Figure 2-4 shows how a sample of a site page might look with grids defining where the content can be placed.

Taking a step back and looking at this image allows you to appreciate some of the beauty that can be achieved using a grid system.

You could continue the process of creating this pixel-perfect grid using HTML and CSS, but why go through all that trouble when someone else already has?

Nathan Smith created the 960 Grid System as a simple way to lay out web sites using a grid that is 960 pixels wide. Using this system, the 960-pixel-width container can now be split into 12- or 16-column grids. In the 12-column version, shown in Figure 2-5, the narrowest column is 60 pixels wide. Each column after that increases by 80 pixels. Ten-pixel margins surround the container and a 10-pixel gutter is also included to separate the columns. Overall, this grid system was one of the most popular and helped pave the way for many different iterations.

The 960 Grid System helped many designers build their designs using the appropriate CSS classes. The CSS classes they used determined the width and surrounding margins for that column(s). With responsive web design, we are building for mobile first and adding features as the resolution increases. Fluid grids expanded on this concept with the grid system(s) in place, to allow for grid column widths to adapt dependent on the device viewport. If the viewport was 768 pixels or 1,200 pixels, the main container and its encompassing columns would adjust accordingly.

Media Queries

Media queries, an aspect of CSS, are not new. CSS2 have supported media-dependent styles but they were limited to basic media differentiations such as for screen or for print. As an example, in Listing 2-1 and Listing 2-2 we see two different methods using CSS2 standards to link to different style sheets based on the media or styles that reference media.

Listing 2-1.  HTML <link> Tag Utilizing Value CSS2 Media Queries

<link rel="stylesheet" type="text/css" media="screen" href="styles-screent.css">
<link rel="stylesheet" type="text/css" media="print" href="styles-print.css">

Listing 2-2.  HTML Styles Utilizing Value CSS2 Media Queries

<style type="text/css">
   @media screen {
       body {font-family: sans-serif; }
   }
   @media print {
      body {font-family: serif; }
   }
</style>

CSS3 builds on media queries previously available by allowing us to filter by more viewport values. Of most importance to responsive web design are viewport width filters. You don’t necessarily have to have multiple style sheets to accommodate all the different screen sizes and browsers that your visitors might use. However, if you do prefer a different style for each design, you can use the code in Listing 2-3, for example, to do so.

Listing 2-3.  In-Line Media Query

<link rel="stylesheet" media="screen and (max-device-width: 480px)" href="480px.css" />
<link rel="stylesheet" media="screen and (min-width: 600px)" href="large.css" />

For CSS3-capable browsers, the styles found in small.css will only be used if the maximum device width of the device is 480px. Two important notes are in order here. First, different browsers will handle a media query in a <link> tag differently. As an example, even though Firefox 9.0 and older versions support media queries, the min-width media query is not recognized but the rules inside the style sheets are still parsed and applied.

Second, older browsers such as Internet Explorer 8.0, which do not support media queries, will ignore the media value and thus download and parse all linked to styles. This could be a problem, so for now, we will want to always include @media blocks in our style sheets as shown in Listing 2-4.

Listing 2-4.  @media CSS3 Tag

@media screen and (max-width: 600px) {
   .sixhundredmaxwidth {
      clear: both;
      font-size: 1.3em;
   }
}

Going back to Listing 2-3, the large.css will only be loaded if the minimum width of the browser is 600px. There are those who prefer, for the sake of efficiency, to have a single CSS file that contains all the styles for different browsers and sizes. This eliminates the need for multiple requests for several different sheets. You can achieve media queries with each individual CSS declaration by using a @media CSS block as seen in Listing 2-4.

In this example we are specifying that the sixhundremaxwidth CSS class should only load when the maximum browser width is 600px. In Listing 2-5, we leverage the mobile handheld’s ability to handle orientation for containers or sections labeled landscape.

Listing 2-5.  Seek Orietation Feature for Intranet

@media screen and (orientation: landscape) {
   .landscape {
      width: 30%;
      float: right;
   }
}

There are many benefits to leveraging media queries in your web sites. Keep these basic techniques in mind as future chapters build on what we’ve just seen.

Flexible Media

Traditionally, any content (text, images, or video) on the web was designed to be suitable for a fixed-width experience. Now that you are building for a responsive web site, you need to start considering how media is going to be viewed on different viewports.

When designing for a responsive web site, say that your <h1> tag is styled with a font size of 26 pixels for the desktop view. What would the font size be for the tablet view or mobile view? You will need to account for font type that is proportionate to the sizes of the view. Similarly, the same thought process can be applied images, video, and other media.

In terms of text, it’s a little bit easier to tame how content is viewed on different viewports. Everyone has his or her own approach, but one of the widely accepted best practices is to start with a base font size from which all other font sizes are proportioned.

Resizing a font is one thing, but trying to resize images and other forms of media introduces other problems. The first problem that you typically face is that if you have a fluid grid layout, media (e.g., images) are typically added using a fixed width. When you resize the image container, the image width does not change and therefore won’t resize to fit within a fluid layout. There is a relatively easy fix to this problem that prevents images from exceeding the width of their containers, shown in Listing 2-6.

Listing 2-6.  Flexible Image CSS Property

img {
   max-width: 100%;
}

A few years ago, defining the maximum width to 100 percent introduced issues with height and width aspect ratio. However, current browsers will resize images proportionally so that the image’s aspect ratio remains intact. What’s great about this simple approach is that we can actually apply this magic rule (max-width) to other media-ready elements (see Listing 2-7).

Listing 2-7.  General Flexible Media Including Older Browser Support

img, embed, object, video {
   max-width: 100%;
   // support for IE5.5, IE6, IE7
   width: expression(this.width > 400 ? 400 : true);
}

This only works if your targeted browsers support the max-width property. Therefore, Listing 2-7 also includes code to support browsers, such as Internet Explorer 5.5, Internet Explorer 6.0, and Internet Explorer 7.0. However, we now run into our second problem. Even if you resize media on your site to dynamically fit within its container, you are still loading the same file for different devices.

As a quick example of this download issue, say we have a large, high-resolution image we place on a particular page and say this image has a file size of 80k because it should display on a 960-pixel-wide design. If we intend to use this same image for a mobile device that has a 320-pixel-wide viewport, the mobile browser will still download the entire 80k image and resize it to fit the viewport. That is a large file to download considering how small it could be if instead we could have provided a smaller image. Furthermore, we might not have even wanted to display the large image at all on a smaller viewport. We’d try to hide the media using display: none. Despite the right intentions, a mobile browser might still download the image before it was hidden.

The second problem can be addressed by leveraging media queries. This means that you can have multiple images with different sizes for each device and browser combination. This obviously poses a different problem, as it can be burdensome to create so many variations of images. Proper planning would be required.

This was just a brief introduction to the three key elements of what makes responsive web design: fluid grids, flexible images, and media queries. The key to remember when designing your site is that responsive web design is not perfect. In the next section, we review a few of the gotchas and best practices when making responsive design part of your web development workflow.

HTML5

HTML5 is the latest markup standard that aims to improve how content is structured and presented. One of the biggest aims is to improve the markup language with support for the latest media. This section covers the new HTML5 features, and we look specifically at how the DOCTYPE has evolved and one of the biggest changes to come HTML5, semantic elements.

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

<?xml version="1.0" encoding="UTF-8"?>
<!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" xml:lang="en" lang="en">
   ...
</html>

<!doctype html>
<html>
   ...
</html>

<!DOCTYPE html>
<html>
   ...
</html>

<!DOCTYPE html>
<html>
   <head>
      <title>Page Title</title>
   </head>
   <body>
      Content goes here....
   </body>
 </html>

<!DOCTYPE html>
<html>
<head>
   <title>HTML5 compliant with HTML4 markup</title>
</head>
<body>
   <div id="header">logo</div >
   <div id="nav">item 1, item 2, item 3</div>
   <div class="article">
      <div class="section"></div>
   </div>
   <div id="sidebar">related links</div>
   <div id="footer">copyright</div>
</body>
</html>

<!DOCTYPE html>
<html>
<head>
   <title>HTML5 document</title>
</head>
<body>
   <header>...</header>
   <nav>...</nav>
   <article>
      <section>
          ...
      </section>
   </article>
   <aside>...</aside>
   <footer>...</footer>
</body>
</html>

CSS3

We know that CSS stands for Cascading Style Sheets and that it’s a markup language that alters, and gives style, to a web site. CSS gives us the ability to separate presentation from HTML markup and further allows us to reuse the styles defined in the CSS for all pages in your web site.

p { color: red; }

<p id="intro">Introducing our latest solution. </p>
<p class="aside">Check out what else we have to offer</p>

p#intro { font-size: 125%; }
p.aside { font-style: italic; }

<p id="intro">Introducing our latest solution. </p>
<p class="aside">Check out what else we have to offer</p>
<p class="aside">Make sure you connect with our partners</p>

@media screen and (max-width: 800px) {
   .class {
      background: #ccc;
   }
}

<link rel="stylesheet" type="text/css" media="only screen and (max-device-width: 480px)"
    href="small-device.css" />

.opacity-test{
   background: red;
   filter: progid:DXImageTransform.Microsoft.Alpha(opacity=60);    /* IE filter extension */
   width:100%;               /* Required for IE filter */
   -webkit-opacity: 0.6;     /* Webkit extension */
   -moz-opacity: 0.6;        /* Mozilla extension */
   opacity: 0.6;             /* the correct CSS3 syntax */
}

.resizable {
        padding: 10px;
        border: 1px solid;
        resize: both;
        overflow: auto;
}

jQuery and Responsive Web Design

Now that you have a basic knowledge of HTML and CSS, we would like to bring your attention to one of the most popular JavaScript libraries, jQuery. If you are not already familiar with jQuery, it is a lightweight, very well supported JavaScript library that lives by the motto, “Write less, do more.” From day one, the purpose of jQuery has been to make it easier to use JavaScript on your web site. jQuery takes a lot of common tasks that require multiple lines of JavaScript code to accomplish and wraps it into methods that you can call with a single line of code. The ease of use, popularity, and vast feature set of jQuery has meant that it’s the best tested cross-browser library. There’s a lot of good to be said about jQuery because much of its functionality has been included in HTML5 specifications.

<html>
<head>
   <title>...</title>
   <script src="//ajax.aspnetcdn.com/ajax/jQuery/jquery-1.9.1.min.js"></script>
   <script>window.jQuery || document.write('<script src="/js/jquery-1.9.1.min.js"></script>')</script>
</head>
<body>
...
</body>
</html>

...
<body>
<div class="boxes">
   <!—some content-->
</div>
<script>
   $(".boxes").css("font-color", "red");
</script>
</body>
...

<script>
   $('.boxes').hover(function() {
      $(this).css('background-color','green'),
    }, function() {
      $(this).css('background-color','transparent'),
   });
</script>

...
<body>
<h1>Showing and Hiding</h1>
<p>With jQuery, it's easy to show and hide elements dynamically.</p>
<h2>Item One</h2>
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</p>
<h2>Item Two</h2>
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</p>
<h2>Item Three</h2>
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</p>
<script>
   $(function() {
      $('h2’).next('p').hide();
      $('h2').click(function(e) {
         $(this).next('p').toggle();
      });
   });
</script>

CSS Style Sheet or Style Sheets?

If we have multiple CSS style sheets, we can use <link> tag-based media queries to help filter what style sheets should load on a particular client device, but as we mentioned different browsers treat <link> tag-based style sheets differently. Further, more files to download increases the number of HTTP requests that the client makes on every page load. Each page request has overhead, not only in CPU cycles but also additional packet overhead.

On the other hand, having one style sheet that utilizes media queries to handle all devices is not advantageous, as it forces low bandwidth or mobile devices to download and process the complete CSS style sheet, much of which it won’t need.

A robust solution centers on a “mobile first” strategy. In this strategy, we build toward mobile devices first; thus we start by building for mobile users and limited display devices and add on functionality as devices allow. (Sounds like progressive enhancement, doesn’t it? Are you starting to see how many methodologies are related?) In this case our first style sheet would be a basic or base style sheet that requires no media devices and at most helps style our fluid grid site so that it can scale in a basic manner on any device without the need for CSS3 or JavaScript.

Our next series of style sheets would be linked to using <link> tags with included media queries. We could include style sheets for mobile, tablet, and desktop enhancements. Why include a mobile style sheet? We might want to include additional CSS3 tagging, transactions, and so on, that could require JavaScript-based feature detection, or we simply want to increase the mobile browsing experience with additional enhancements if allowed. We must remember that our additional style sheets should also include media queries in case a browser decides to, or is unable to, filter by the <link>-based media query. Refer to Listing 2-27 for an example of linking to multiple style sheets and Listing 2-28 for an excerpt of the style sheets themselves.

Listing 2-27.  Linking to Multiple Style Sheets

<!DOCTYPE html>
<html>
<head>
   <title></title>
   <link rel="stylesheet" type="text/css" href="basic.css" />
   <link rel="stylesheet" type="text/css" media="all and (max-width: 767px)” href="mobile.css" />
   <link rel="stylesheet" type="text/css" media="all and (min-width: 768px) and (max-width: 959px)”
      href="tablet.css" />
   <link rel="stylesheet" type="text/css" media="all and (min-width: 960px)" href="desktop.css" />
</head>
...
</html>

Listing 2-28.  basic.css, mobile.css, tablel.css, and desktop.css Style Sheets

basic.css
body {
   font-family: sans-serif;
   color: #222;
   font-size: .6em;
}

mobile.css
/*any screen smaller than most tablets*/
@media all and (max-width: 767px) {
   body {
      color: #444; /*change the font color*/
      font-size: .8em;
   }
}

tablet.css
/*any screen between most tablets and a minimal desktop experience based on a 960px grid*/
@media all and (min-width: 768px) and (max-width: 959px) {
   body {
      color: #666; /*change the font color*/
      font-size: .95em;
   }
}

desktop.css
/*any screen based on a general desktop experience with a max width of 1200px*/
@media all and (min-width: 960px) {
   body {
      color: #888; /*change the font color*/
      font-size: 1.1em;
   }
}

The simplicity of this approach provides us the ability to limit the bytes downloaded, yet at the same time provides a reasonable experience on most any device. This is easy in theory but difficult in practice as sites grow in complexity, which changes the way most web developers have been building web sites; that is, focusing on the desktop experience.

My Site Requires JavaScript

Don’t forget that a site should at least load and be functional without requiring JavaScript. This might mean our CSS, by default, should hide some aspects of our site, such as rotating banners based on our minimal site requirements. If you “require” JavaScript you are doing some of your potential visitors a disservice. If you are running a public-facing site on SharePoint, you can limit the damage inflicted when a visitor accesses your site yet doesn’t allow JavaScript. There’s an advantage to limiting your reliance on JavaScript, as it provides improvements for search engine optimization as well as accessibility. For your site administrators, you will have to require JavaScript, as much of SharePoint’s administrative functionality is driven off of the Office Suite bar and the ribbon.

Once you have finished the primary build of your site, you might find it advantageous to minimize and combine your JavaScript and jQuery plug-ins into one large .js file. Even if all plug-ins and scripts are not required on every page, once the script has been downloaded, most browsers will cache this file. Further, keep in mind that the fewer files our page downloads, the fewer HTTP requests your site visitors make. This is beneficial, as it will help improve performance and page load time.

There’s Always a Better Approach

Responsive web design as a methodology is still improving and is often supplemented with additional design theories that we have already reviewed including adaptive web design, mobile first, and in SharePoint 2013, supplemented with separate mobile, like features found in device channels. It is important to remember that there is no silver bullet approach; rather, each project is unique and might use a combination of approaches to achieve the desired outcome. Here’s what you can do to tailor user experiences to your visitors:

1. Review your traffic logs and determine what mobile devices are accessing your site today.
2. Test your site on those devices and determine where the experience breaks down.
3. Develop an action plan to address the issues that you face. Focus on the critical path and test.

Once you’ve addressed this, pat yourself and your team on the back and when you’re ready, go back go to Step 1 and start again, as the landscape will likely have changed and you do not want to be left behind.