Responsive Data Table Roundup

There has been a bunch of takes on responsive data tables since I first published about it.

The idea of the original was to abandon the grid layout of the table and make each cell its own line. Each of those lines is labeled with a pseudo element. This creates a much taller table, requiring more vertical scrolling, but does not require horizontal scrolling. It’s easier to browse the data without losing the context of what’s what. The downside is that you might lose the context of data comparison since you no longer see cells of data right next to other cells of that type.

Mobifreaks published a very similar idea, which uses the same layout change and pseudo element labeling. They used HTML5 data-* attributes for the labeling, which removes the need to have custom CSS for different tables. I don’t buy into the SEO part, but the code is good.

Derek Pennycuff took the original and applied the “mobile first” concept. Instead of starting with table markup it starts with definition list markup, then forces it into a table layout when the screen is large enough to accommodate it. While I love the thinking here, I’m not sure I like what it takes to get it done. The markup is much heavier and (ironically) I don’t think it’s semantic. Tabular data should be marked up as a table. I think the philosophy behind “mobile first” is keeping things simple and lighter by default and heavier and more complex for larger screens. This demo starts out and stays heavy.

Drew Dyksterhouse made a demo that calculates where the table should break by measuring if the table has become wider than the screen, then saving that breakpoint for efficiency.

Scott Jehl cooked up two clever ideas. One was to build a chart from the data in the table. In this demo, it’s pie chart that is much narrower than the complete data table and thus more suitable for small screens.

Pretty cool, but clearly all tables can’t be converted into charts. I’d also argue a data table and a chart are pretty different things. If you are going to go through the trouble of making a chart, it would probably be good to show that to the larger screen as well as it provides context in a useful alternative way. Or at least have an option to see it.

Scott’s other idea focuses on the problem that large data tables can stretch out the width of a parent container beyond what a small screen is capable of displaying. So to prevent this, a media query is used to hide the table on small screens, replaced with a small mock-table and a link to view the full table.

Stewart Curry had the idea of just hiding less important columns for smaller screens. One of people’s earliest gripes of mobile-specific sites was that just because they are on a mobile device doesn’t mean they deserve a less-than-full experience than a user with a larger screen (especially since these devices are totally capable of maneuvering around “full” sites).

I think Stewart was on to something though. Using small screens to focus information to the most important things is great, it just shouldn’t lock away information with no recourse. Maggie Costello Wachs of Filament Group also had the idea of hiding non-essential columns on smaller screens, but also providing a dropdown menu where you can re-enable them if you wish (which you can get to see with horizontal scrolling).

David Bushell also tackled the idea of not altering the basic table format, but still solving the “too wide” problem. His concept flips the table on it’s side and applies overflow-x: auto to the tbody meaning the data cells can scroll left and right if it breaks out of a small screen, but you still always see the headers (as if they were fixed position).

Brad Czerniak has an idea he calls Rainbow Tables where on smaller screens the grid structure of the table is abandoned and the data cells are squished into each other as tight as they will go, while still being a “row”. Then instead of the data be identified by which column it is in, the data is color-coded to match a key.

Update May 26, 2012: Zurb has a new technique they’ve published. It is focused on having the left-most column be sort of the “key” column. On wide screens, it’s just a normal column. On small screens, it becomes fixed/sticky to the left and the rest of the columns can scroll. This allows for row-to-row comparison.

It is similar to David Bushell’s technique with the fixed left column, but perhaps a bit more robust as it utilizes JavaScript for a bit of DOM manipulation and screen size measurement. Extra dependencies, deeper support, your call.

Updates

Here’s some more that have cropped up:

• Filament Group combined several of the very best patterns together into a “A group of plugins for responsive tables” called Tablesaw.
• Stackable.js
• FooTable
• jQuery-rt-Responsive-Tables
• RWD-Table-Patterns

Also, Jason Grigsby has an article on choosing a solution based on what the user would want to do with the table.

To make this an even harder problem, consider what markup you’d have to start with to make the data work with no CSS at all, as well as no JavaScript. The idea is then it could go out to email and RSS and stuff and be OK. I tried to tackle that here. It’s pretty messy, but it works.