Topics:

progressive enhancement

responsive design

As we create responsive websites, we must consider a number of factors to make sure both the design and code are as bullet-proof as possible: the design must scale across a wide range of screen sizes from mobile to tablet to desktop; and the code must start with a mobile-first approach, work well for screen readers or with JavaScript disabled, and be robust enough to adapt to differences in text size and rendering across devices or user settings.

Adapting site navigation to be understandable, usable and attractive across a wide range of devices is particularly challenging. On the Boston Globe site, we gained some key insights about how to build robust mobile-first responsive navigation systems. This is the first in a series of articles in which we'll explore navigation design techniques from very simple nav bar design, to complex multi-level hierarchies, search, and fuller featured navigation systems.

Truly responsive navigation

Using progressive enhancement, CSS media queries, and a little JavaScript, we built a navigation list that adjusts to fit the size of the screen and adapts to differences in text sizing. View the demo

We're in the process of rethinking our site design, so we used our own navigation list as a test case. It consists of 5 options — What We Do, What We've Done, What We're Thinking, Who We Are, and Contact Us. These options can take up a lot of space on a tiny mobile screen, so our goal was simple: for smaller screens we'll make the navigation as compact as possible to save room for the main content, and on larger screens with ample space we'll display all options in a horizontal bar for quicker access.

We marked up a standard unordered list of links, usable on any device that renders HTML, layered on a few mobile-friendly styles to make the hit area bigger for finger taps, and then added a little JavaScript to transform the list into a custom dropdown menu. Users that don't have JavaScript enabled will just see the full list — no harm, no foul.

For larger screens, we used CSS3 media queries to display the options in a horizontal bar. We wanted to ensure that the screen has enough room to display the entire bar in a single line (we don't want the nav or its options to wrap because, in this case, wrapping would make the page look broken or mess with the navigation hierarchy), so we estimated the minimum width value: width of the horizontal navigation bar + the width of any neighboring elements + a little wiggle room. We tested this breakpoint across a wide range of browsers, and increased the value when we saw options wrap.

We could've stopped there, but we can't forget that screen size is just one of many factors that effect how a layout is displayed. Take text rendering, for example: the type, size, and shape of fonts can vary among operating systems/browsers, and users have the option to adjust sizing with browser controls. (And, as Stephanie Rieger notes, the list of user-controlled variables is growing.) So, while it makes sense to use media queries as a baseline for altering the layout, we made our navigation bar feel smarter and more responsive with a little JavaScript to detect whether the horizontal nav bar fits in the available space, regardless of screen size; when the fit test fails, the navigation remains a custom dropdown menu.

The final result is a navigation list that's optimized for use on a wide range of screen widths and with variable text sizes. We'll walk through this example in detail below.

Markup

The menu is a list of links, so that's what we'll use: a standard unordered list with anchor tags. We'll group the list with a heading to identify the navigation element, "Sections", and give the outer container a descriptive class for scoping styles, nav-primary.

<div class="nav-primary">
   <h3>Sections:</h3>
	<ul>
		<li><a href="http://www.filamentgroup.com/services">What We Do</a></li>
		<li><a href="http://www.filamentgroup.com/portfolio">What We've Done</a></li>
		<li><a href="http://www.filamentgroup.com/lab">What We're Thinking</a></li>
		<li><a href="http://www.filamentgroup.com/about">Who We Are</a></li>		
		<li><a href="http://www.filamentgroup.com/contact">Contact Us</a></li>
	</ul>
</div>

We'll assign the class nav-current to the active navigation option; this will come in handy later when we create the custom dropdown menu.

<li class="nav-current"><a href="http://www.filamentgroup.com/services">What We Do</a></li>

To round out our example, we'll add the Filament Group logo and a small block of content. For screen readers we'll provide a "skip navigation" link so that they don't have to navigate through the list on every page.

<a href="http://www.filamentgroup.com/" id="logo"><img src="fg-logo.gif" alt="Filament Group, Inc." /></a>

<a href="#main" class="skip">Skip navigation</a>

<div class="nav-primary">
   <h3>Sections:</h3>
	<ul>
		<li class="nav-current"><a href="http://www.filamentgroup.com/services">What We Do</a></li>
		<li><a href="http://www.filamentgroup.com/portfolio">What We've Done</a></li>
		<li><a href="http://www.filamentgroup.com/lab">What We're Thinking</a></li>
		<li><a href="http://www.filamentgroup.com/about">Who We Are</a></li>		
		<li><a href="http://www.filamentgroup.com/contact">Contact Us</a></li>
	</ul>
</div>

<div class="content">
   <p>We offer services from strategy to UI and application design, to accessible front-end code development, and happily work with clients to find the right mix that supports their internal capabilities.</p>
</div>

Before we wrap up the markup, we want to make sure that our page content is sized to fit the screen, so we'll add a viewport meta tag (how the viewport meta tag works):

<meta name="viewport" content="width=device-width, initial-scale=1">

We now have a legible, usable page to which we can add style and behavior enhancements.

Styles for the small screen

If you're not familiar with using CSS3 media queries to render pages responsively, we highly recommend Ethan Marcotte's definitive article, Responsive Web Design, and book by the same title.

We'll start with a few basic styles that make the links easier to read and tap on small screens (a block display property and padding, and a font-size that's large enough for finger-based gestures), and a few additional styles to make the list easier to scan (borders between options, and bold text for the active option). We'll also hide the "Sections" heading (h3), but in a way that keeps it accessible to screen readers.

.nav-primary h3 {
   position: absolute;
   left: -999em;
}
.nav-primary ul {
   border: 1px solid #e6e6e6;
}
.nav-primary li {
   font-size: 1.8em;
   border-bottom: 1px solid #eee;
}
.nav-primary li:last-child {
   border-bottom: 0;
}
.nav-primary a {
   display: block;
   padding: .5em .8em;
   text-decoration: none;
   color: #333;
}
.nav-primary a:hover {
   background-color: #f8f8f8;
}
.nav-primary .nav-current {
   font-weight: bold;
}

We'll add a few more rules to style the overall page, logo and content blocks, and another rule to make the navigation play nicely with them (clear the logo, and add space before the content). We want the "skip" link to be available to screen readers but hidden from everyone else, so we'll position it off the page.

body {
    font: 62.5%/1.4 helvetica, arial, sans-serif; 
    padding: 2em 1em;
}
#logo {
   float: left;
   margin: 0 0 1em; 
}
.content {
   clear: both;
}
p {
   font-size: 1.8em;
   line-height: 1.4;
   margin: 0 .3em 1em;
}
a.skip {
   position: absolute;
   left: -999em;
}

...

.nav-primary {
   clear: left;
   margin: 0 0 2em;
}

...and for larger screens, like tablets and desktops

Our page looks nice at smaller screen widths, but on a larger screen, each option stretches to fill the space and the navigation dominates the page.

To fix this, we'll add a couple of rules, scoped within a media query, to display the navigation as a horizontal bar in screens that are 640px wide and larger (640 = full width of the navigation + body padding).

We'll float each navigation option to the left, remove the border between options, and assign a slightly smaller font size. We'll also float the navigation block itself and the list container so that they fully contain their floated child elements.

@media screen and (min-width: 640px) {
   .nav-primary,
   .nav-primary ul {
      float: left;
   }
   .nav-primary ul {
      float: left;
   }
   .nav-primary li {
      float: left;
      font-size: 1.5em;
      border-bottom: 0;
   }   
}

Much better.

When the screen is wide enough to fit the logo and nav side-by-side — 910px, specifically — we'll float the navigation block to the right. We arrived at that number by adding the width of the logo (250px) to the width of the navigation list displayed horizontally (640px), plus a little extra margin to account for slight browser rendering differences (20px).

@media screen and (min-width: 910px) {
   .nav-primary {
      float: right;
      clear: none;
   }   
}

Our navigation now assumes one of two forms in response to the screen's size: a list on smaller screens, or a horizontal bar on larger screens.

As it stands, our navigation looks pretty good on a range of screen sizes — but there is definitely room for improvement. On small screens, our navigation list still takes up a good chunk of vertical space, and on larger screens, our horizontal navigation bar wraps when we increase our browser's text size. Bump up the text a couple of times on a tablet-sized screen and the options wrap to a second line:

And at larger sizes, the entire navigation bar wraps under the logo, creating odd gaps of white space:

So we have two issues left to address:

• transform the navigation into a compact, custom dropdown menu when screen space is limited, and
• create a test to determine if navigation options will fit on a single line, or if the entire bar will fit next to the logo on larger screens; if not, show the compact menu.

We'll start with menu styles, and then fill in the test logic.

Styles for a compact menu

We'll write styles to hide all options by default except for the active option, nav-current, and display the "Sections" heading as a clickable dropdown button positioned to the right. We'll add another class, expanded, that we'll toggle with JavaScript to show/hide the full list of options.

Note that these styles are all scoped to the class, nav-menu. Later, our test logic will toggle this class on the body tag.

.nav-menu .nav-primary {
   margin: 0 0 1.5em;
   position: relative;
   overflow: hidden;
}
.nav-menu .nav-primary a {
   padding-right: 3em;
}
.nav-menu .nav-primary h3 {
   position: absolute;
   top: 0;
   left: auto;
   right: 0;
   display: block;
   width: 4em;
   height: 4.5em; 
   background: #ccc url(img/icons.png) no-repeat -205px 45%;
   text-indent: -999em;
   cursor: pointer;
}
.nav-menu .nav-primary.expanded h3 {
   background-position: -169px 45%;
}
.nav-menu .nav-primary li {
   clear: left;
   display: none;
}    
.nav-menu .nav-primary.expanded li,
.nav-menu .nav-primary li.nav-current {
   display: list-item;
} 
.nav-menu .nav-primary li.nav-current {
   border-bottom-width: 0;
}
.nav-menu .nav-primary.expanded li.nav-current {
   border-bottom-width: 1px;
}

Now, when JavaScript is enabled, the menu will take a more compact form:

Next, we'll write a bit of JavaScript to ensure that our navigation bar fits the available space.

Does the navigation fit?

We'll bind a custom event, "testfit", to the navigation container. We'll trigger this event when the page loads, and when the screen changes size or orientation. (A nice side effect: desktop browsers that support text zooming, like the latest versions of Chrome, Firefox, and Opera, trigger the resize event — and this test — when the user increases or decreases text sizing with browser controls or key commands.)

$('.nav-primary')
   // test the menu to see if all items fit horizontally
   .bind('testfit', function(){
      // ...logic goes here...
   }) 
   
   // ...and update the nav on window events
   $(window).bind('load resize orientationchange', function(){   
      $('.nav-primary').trigger('testfit');
   });

When the test passes, we'll add the nav-menu class to the body. One of the following conditions must be met for "testfit" to pass: when the entire nav wraps to a second line under the logo, or when any of the navigation options wrap to a second line. In both cases, we test for wrapping by comparing top offset values, which can be effected by changes in screen or text size. When the navigation's top value is greater than the logo's, the navigation has wrapped to the next line; when the last navigation option's top value is greater than the first, it's wrapped.

We'll also remove the nav-menu class from the body to reset the styles before the test is run.

$('.nav-primary')
   // test the menu to see if all items fit horizontally
   .bind('testfit', function(){
      var nav = $(this),
            items = nav.find('a');
      
      $('body').removeClass('nav-menu');                                
      
      // when the nav wraps under the logo, or when options are stacked, display the nav as a menu              
      if ( (nav.offset().top > nav.prev().offset().top) || ($(items[items.length-1]).offset().top > $(items[0]).offset().top) ) {
      
         // show the menu -- add a class for scoping menu styles
         $('body').addClass('nav-menu');
      
      };           
   })
      
   ...

Finally, we'll assign a click event to the heading element to show/hide the menu options.

$('.nav-primary').find('h3')
   .bind('click focus', function(){
      $(this).parent().toggleClass('expanded')
   });

We now have a menu that is responsive to differences in screen size (view the demo):

..and text size:

Keep the conversation going

The pattern discussed here is one possibility for coding a responsive navigation list. We hope to discover more, and will update our RWD-Nav-Patterns git repository as we build additional examples.

This demo code is open source and available for download. Feel free to put it through its paces. If you use it and see room for improvement, please submit a pull request and we'll review it as soon as possible.

Topics:

progressive enhancement

responsive design

In responsive web design, one of the toughest design problems to solve is how format complex tabular data for display on smaller screens. In this post, we'll explore an experimental approach to rendering a complex table, using progressive enhancement and responsive design methods, that displays comfortably at a wide range of screen sizes, provides quick access to the data, and preserves the table structure so that data can still be compared across columns.

We've been batting around the idea of making tables responsive for awhile.

Our initial attempts to make table data palatable on small screens include showing a thumbnail image that links to the data or a canvas-based chart; others have developed responsive CSS workarounds that display a definition list, using either list or table markup. Which approach to take depends on the type of data. For example, structured data where each row is a unique object or entity—say, business contacts, or favorite Netflix movies—are well-suited to a definition list style on small screens, because header and cell data can be displayed as simple label and value pairs (i.e., Name: Maggie Wachs, Company: Filament Group...). The switch to a chart or other visualization on smaller screens works well for a simple numeric comparison of a single value. And snapping down to a thumbnail image that launched a full table to pan and zoom was an okay fallback in lieu of no data at all.

But we encountered a scenario that didn't quite work with any of the above solutions: a table of complex of financial data with 6-8 related data points, where comparisons and trends among columns are important to see. Visual relationships between headings and cells, and between neighboring columns, are crucial to understanding the data and would be lost on smaller screens if we displayed a list or chart.

We needed a happy medium: a way to keep the basic table structure in place—with headings above, and whole columns that sit side-by-side—and simultaneously display a manageable amount of data at a size that's comfortably readable.

A table for every screen

The approach we devised starts with a full data set, and uses a simple priority-based class designation to display a manageable subset of data columns for common target screen sizes, and also gives the user control to change column visibility easily.

It's probably easier to explain with a concrete example: we'll use a table that lists technology companies and their stock prices and several stock performance metrics. Each row displays data for a single company; columns organize data points by type for comparison. View the demo.

All data columns will display on desktops and tablets in landscape orientation, but only a subset will fit comfortably on anything smaller. So the first order of business is to identify which columns of data are essential to see at all screen widths by default, or optional (shown only when space allows). In our table of tech company stocks, the data is somewhat meaningless without the company name, current stock value, or most recent change, so we'll consider those essential. The trade time, previous close, and open values would be nice to see if the screen can fit those columns, so we'll make them optional. The remaining data—bid, ask, and 1-year target estimate—are less important in relative terms, so they will appear on only the widest screens.

View larger image

In this case, we want users to have the last word regarding which columns to show, so we'll also create a custom menu that lets them choose which columns to display:

The final result is a table that displays a limited set of columns on smaller screens, and provides quick access to data that's hidden because of space constraints (view the demo). To accomplish this, we'll use progressive enhancement to ensure that we're serving a usable experience to all devices. We'll start with well-formed, semantic table markup and very basic CSS, and then if the browser is capable, apply JavaScript and enhanced CSS (including media queries) to conditionally show a larger number of columns as screen space allows.

Markup

A basic table — with consecutive columns and descriptive headings — is an efficient way to display a complex data set; data arranged into columns and rows are easy to scan and compare. So an HTML table is the clear markup choice for our financial data.

We'll start with a well-formed table that contains a thead for the heading row, followed by a tbody for the cells.

<table cellspacing="0" id="tech-companies">
   <thead>
      <tr>
         ...header cells...
      </tr>
   </thead>
   <tbody>
      ...rows of data...
   </tbody>
</table>

As we fill in the content, we'll add descriptive classes to identify the essential and optional content. We'll assign these classes only to the headers; later, we'll write a little JavaScript to map these headers to their respective columns of data.

<thead>
   <tr>
      <th class="essential persist">Company</th>
      <th class="essential">Last Trade</th>
      <th class="optional">Trade Time</th>
      <th class="essential">Change</th>
      <th class="optional">Prev Close</th>
      <th class="optional">Open</th>
      <th>Bid</th>
      <th>Ask</th>
      <th>1y Target Est</th>
   </tr>
   ...
</thead>

Notice that we added a second class to the Company header, persist. Essential columns are present by default at small screen sizes, but we'll still be able to toggle their visibility with the custom menu. Marking the Company column with this class provides a way for us to omit it from the menu, and prevent it from being hidden.

We'll complete the table with rows of data that correspond to the column headers:

<table cellspacing="0" id="tech-companies">
<thead>
   ...
</thead>
<tbody>
   <tr>
      <th>GOOG <span class="co-name">Google Inc.</span></th>
      <td>597.74</td>
      <td>12:12PM</td>
      <td>14.81 (2.54%)</td>
      <td>582.93</td>
      <td>597.95</td>
      <td>597.73 x 100</td>
      <td>597.91 x 300</td>
      <td>731.10</td>
   </tr>
   ...
</tbody>

Later when we apply JavaScript, we'll create a custom menu based on the table's content and append it to the page, immediately above the table. The menu will consist of a container element for a "Display" button and the menu overlay:

<div class="table-menu-wrapper">
   <a href="#" class="table-menu-btn">Display</a>
   <div class="table-menu">
      ...menu content...   
   </div>   
</div>

The menu overlay will contain a list of options, one for each column, where each option has a label and checkbox input for toggling that column's visibility (columns with the persist class will be excluded from the menu):

<div class="table-menu-wrapper">
   <a href="#" class="table-menu-btn">Display</a>
   <div class="table-menu">
      <ul>
         <li>
            <input type="checkbox" name="toggle-cols" id="toggle-col-1" value="co-1">
            <label for="toggle-col-1">Last Trade</label>
         </li>
         <li class="optional">
            <input type="checkbox" name="toggle-cols" id="toggle-col-2" value="co-2">
            <label for="toggle-col-2">Trade Time</label>
         </li>
         ...
      </ul>   
   </div>   
</div>

When the script builds the menu, it will automatically assign name and value attributes and unique IDs to the input elements, and matching for attributes to their labels.

Last but not least, we'll wrap the table in a container element to simplify positioning the menu:

<div class="table-wrapper">
   <table cellspacing="0" id="tech-companies">
      ...
   </table>
</div>

CSS

We'll assume you're already familiar with using CSS3 media queries to render pages responsively. If not, we highly recommend Ethan Marcotte's definitive article, Responsive Web Design, and book by the same title.

Let's start with the table. We want it to fill the available space, so we'll assign a width of 100%:

table {
   width: 100%;
   font-size: 1.2em;
}

And then apply color, padding, and alignment properties to make the data easier to scan:

thead th {
   white-space: nowrap;
   border-bottom: 1px solid #ccc;
   color: #888;
}
th, td {
   padding: .5em 1em;
   text-align: right;
}
th:first-child, 
td:first-child {
   text-align: left;
}
tbody th, td {
   border-bottom: 1px solid #e6e6e6;
}

Next, we'll write the rules that hide and show columns. We've scoped these styles to a class, enhanced, which is assigned to the table via JavaScript. This ensures that column visibility is altered only when JavaScript is available. By default, we'll hide all columns, and show only those marked with the essential class:

.enhanced th,
.enhanced td {
   display: none;
}
.enhanced th.essential, 
.enhanced td.essential {
   display: table-cell;
}

Using CSS3 media queries, we'll show optional columns when the browser is 500px wide or greater, and all columns at 800px or greater:

@media screen and (min-width: 500px) {
   .enhanced th.optional, 
   .enhanced td.optional {
      display: table-cell;
   }
}

@media screen and (min-width: 800px) {
   .enhanced th, 
   .enhanced td {
      display: table-cell;
   }
}

When using this approach, how you prioritize and categorize your data must correspond to the number of screen size breakpoints you plan to support. In our example, we've chosen to have two breakpoints, at 500 and 800 pixels wide, and two levels of importance, essential and optional. If we were to add another break point, say around 400px, we would need to rework our categories to include a third (i.e., primary, secondary, tertiary) so that we can mark each column to be visible at a particular breakpoint.

When the custom menu is inserted into the table's container, it will appear just above the table on the right:

.table-menu-wrapper {
   position: absolute;
   top: -3em;
   right: 0;
}

The menu itself will also be absolutely positioned, and by default will be hidden with the table-menu-hidden class (later, we'll write JavaScript to toggle that class when the "Display" button is clicked):

.table-menu {
   position: absolute;   
   right: 0;
   left: auto;
   background-color: #fff;
   padding: 10px;
   border: 1px solid #ccc;
   font-size: 1.2em;
   width: 12em;
}
.table-menu-hidden {
   left: -999em;
   right: auto;
}

Finally, we'll add relative positioning to the table's container. Later, when we append the menu we can position it without having to calculate location coordinates:

.table-wrapper {
   position: relative;
   margin: 5em 5%;
}

JavaScript

The table we just created is usable on its own; any browser that renders HTML will display it. With a few JavaScript enhancements, we'll be able to view the table at smaller screen sizes without sacrificing the table structure. (The following examples use jQuery.)

First we'll append the enhanced class for scoping styles:

// add class for scoping styles - cells should be hidden only when JS is on
table.addClass("enhanced");

We'll create a container element for the menu, which will come into play a little later in the script:

var container = $('<div class="table-menu table-menu-hidden"><ul /></div>'); 

Then we'll enhance the markup with classes and attributes that allow us to control column visibility. We'll loop through the table headers and assign them unique IDs, then reference those IDs in headers attributes assigned to associated cells. (The headers attribute identifies to which header(s) a cell belongs.) We'll also copy the classes that we assigned to the column headers — essential and optional — and assign them to the associated columns.

$( "thead th" ).each(function(i){
   var th = $(this),
      id = th.attr("id"), 
      classes = th.attr("class");  // essential, optional (or other content identifiers)
         
   // assign an ID to each header, if none is in the markup
   if (!id) {
      id = ( "col-" ) + i;
      th.attr("id", id);
   };      
         
   // loop through each row to assign a "headers" attribute and any classes (essential, optional) to the matching cell
   // the "headers" attribute value = the header's ID
   $( "tbody tr" ).each(function(){
      var cell = $(this).find("th, td").eq(i);                        
      cell.attr("headers", id);
      if (classes) { cell.addClass(classes); };
   });
   ...      

Next, while still looping through the headers, we'll create a menu item for each column, except for those marked with the persist class. Each menu item consists of a checkbox and label with the column header text.

   ...  
   // create the menu hide/show toggles
   if ( !th.is(".persist") ) {
   
      // note that each input's value matches the header's ID; 
      // later we'll use this value to control the visibility of that header and it's associated cells
      var toggle = $('<li><input type="checkbox" name="toggle-cols" id="toggle-col-'+i+'" value="'+id+'" /> <label for="toggle-col-'+i+'">'+th.text()+'</label></li>');
      
      // append each toggle to the container
      container.find("ul").append(toggle);         
      
      ...   

And then we'll bind events to each checkbox for controlling that column's visibility.

      ...  
      
      // assign behavior
      toggle.find("input")
      
         // when the checkbox is toggled
         .change(function(){
            var input = $(this), 
                  val = input.val(),  // this equals the header's ID, i.e. "company"
                  cols = $("#" + val + ", [headers="+ val +"]"); // so we can easily find the matching header (id="company") and cells (headers="company")
         
            if (input.is(":checked")) { cols.show(); }
            else { cols.hide(); };		
         })
         
         // custom event that sets the checked state for each toggle based on column visibility, which is controlled by @media rules in the CSS
         // called whenever the window is resized or reoriented (mobile)
         .bind("updateCheck", function(){
            if ( th.css("display") ==  "table-cell") {
               $(this).attr("checked", true);
            }
            else {
               $(this).attr("checked", false);
            };
         })
         
         // call the custom event on load
         .trigger("updateCheck");  
         
   }; // end conditional statement ( !th.is(".persist") )
}); // end headers loop   

After closing the headers loop, we'll bind our custom event to the window's resize and orientation change events:

// update the inputs' checked status
$(window).bind("orientationchange resize", function(){
   container.find("input").trigger("updateCheck");
}); 

And, last but not least, append our checkbox menu to the page and bind show/hide menu events:

var menuWrapper = $('<div class="table-menu-wrapper" />'),
   menuBtn = $('<a href="#" class="table-menu-btn">Display</a>');
      
menuBtn.click(function(){
   container.toggleClass("table-menu-hidden");            
   return false;
});
      
menuWrapper.append(menuBtn).append(container);
table.before(menuWrapper);  // append the menu immediately before the table

// assign click-away-to-close event
$(document).click(function(e){								
   if ( !$(e.target).is( container ) && !$(e.target).is( container.find("*") ) ) {			
      container.addClass("table-menu-hidden");
   }				
}); 

Media query support for IE: Respond.js

Older versions of IE (8 and earlier) don't natively support CSS3 media queries, so we need to use a workaround in those browsers to implement our responsive table. Thanks to our own Scott Jehl, we can use a lightweight polyfill script, respond.js, that enables support for min- and max-width media query properties. The script is open source and available on github.

Keep the conversation going

The pattern discussed here is one possibility for coding a responsive table. We hope to discover more, and will update our RWD-Table-Patterns git repository as we come across additional use cases.

This demo code is open source and available for download. Feel free to put it through its paces. If you use it and see room for improvement, please submit a pull request and we'll review it as soon as possible.

Related plug-ins

We release open source code, including the design pattern here, to encourage collaboration — so we're especially excited to learn of new plugins that extend our work.

MediaTable (in Italian), developed by Marco Pegoraro, is a jQuery plugin that applies responsive behavior to one or more standard tables on a page, and also automates the creation of a menu for showing and hiding columns. It's similar to what we've done here, but in "official" plugin format. The code is open source and available on github. Thanks, Marco!