Responsive Data Table Roundup
Published by Chris Coyier
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 context of what's what. The downside is that you might lose the context of data comparison, since you no longer see 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 accomodate 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.
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 an 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.
View Demo
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 around 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 dependancies, deeper support, your call.
Updates
Here's some more that have cropped up:
My favourites are your idea and the one where you chose what data to show.
Very nice collection and examples. I’ve been wondering ways lately to tackle this very subject. Whether to decrease font-size to to start knocking out columns via nth-child.
The pie graph example is especially impressive. I’ll definitely have to give that one a try. Thanks for the resources!
i would tweak your idea a little by only displaying first name and last name at first, and on click show the rest of the information avaliable for the person wich row you clicked.
probably with jquery height change in a a overflow-x hidden if i would think about how to do it.
I believe it’s a non-issue because the false premise here is that you always have to fit stuff to the screen size. It’s always, and I mean always, a search for fool’s gold when trying to anticipate and prepare for every screen size. Especially weird and awkward ones.
One has to focus on how make the tabular data easier to browse, not to set it self goals that aren’t help the user much but instead they annoy the hell out of him with awkward UX.
If on a given mobile device tables aren’t easy to browse through, than it’s safe to assume pretty much everything else isn’t. So that person would be forced to purchase a better device, or it will never appreciate efforts like table-shrinking since it’s not that type of a user.
And newer mobile devices have hard and soft capabilities that makes a non-issue out of table’s display. So the main concern is actually not the table’s width or height but its readability at a first glance.
Oh, and nothing is new here: the part where you switch the columns to rows was used since the MS-DOS days in FoxPro.
We had pretty big tables too then, and scrolling on a 80 chars width screen was just fine :)
Great article. A very interesting combination of ideas here.
I feel that Maggie Costello and David Bushell solutions are the strongest in a sense of usability. Making the most important/relative data immediately available without compromising the interface design too much seems like a win in this scenario.
I really appreciate the combination of images with the descriptions here. Made it very easy to follow along and grasp the concepts presented in the article.
This is a neat CSS trick! I do wonder though, why are you using static website (Html/Css) based for dynamic info? There are other web applications, i.e. a CMS for one, that could generate dynamic reporting information by a few simple PHP code. Think about the number of hours spent styling the table and inputting the data which is constantly changing; hence the term “dynamic”.
My vote goes to David Bushell’s idea. I think that’s the best option I’ve seen.
Excellent tricks. Congratulations for teh site, I like it!
+1 for the David Bushell idea from me. switch columns to rows depending on which is longer.
You could also add this to give iOS 5 users a scroll bar.
overflow: scroll;
-webkit-overflow-scrolling: touch;
I know every table is going to be different based on your data and its display purpose…but over all David Bushell’s solution is GREAT! The experience is perfect on iPhone.
Thank you for your productive examples!!! GREAT
Great, until today i don’t know much about these responsive tables… thanks again!
Lovely roundup. I do love a nice table! ;)
This one goes straight into my bookmarks. Now If I can only find a project to implement it. Every page element needs to be able to be responsive without the use of js
Super tricks! My congratulations for the site =)
Why are people congratulating you on the site ? Did I miss something ?
nice tutorials with awesome designe
Very good round up and one I’ll bookmark. Responsive web design is the only way to build new sites now but dealing with real world problems like this is something we are all coming to terms with. It’s easy to create portfolio sites responsively but creating complex data driven stuff is another matter and the multitude of different layouts for different elements on large scale web sites is something that will be giving me a headache for a while yet. Great stuff thanks.
I solved the IE display Block issue by replacing all the table selectors with DIVs via jQuery. I used your CSS, and I think this is a good solution.
http://www.useyourfred.com/2012/01/js-in-my-sexy-responsive-data-tables/
Hope this helps out!
+1 for David Bushel’s solution. Seems perfect.
Agreed on David Bushel’s solution. It is phenomenal. Can’t wait to try it out.
One version I haven’t seen is organizing a comparison table whose criteria is in the first column as opposed to the header, and reading the data by column as opposed to by row.
Hi,
I like the whole round-up here that shows we are heading to a definite solution. What I would like to see is your original idea and instead of viewing the entire data in a vertical scroll, use css3 and :target to create tabs where each tab is an occurrence of a rowset. What you get? a single view of data with tabs [1] [2] [3] … of the rest of the data.
I really don’t know if this possible, perhaps worth the try. Any takers?
Wow! This is what I need. Is this available as WP Plugin?
This is no doubt an issue with smoothly integrating responsive themes. Tabular data is real data, pervasive in many websites and I’d love to find a way to have this work within a mobile viewport.
What would be nice for targeting smartphones is if we could treat it somehow like a multi-pane element and scroll through it pane by pane sort of like how you’d do it with something like jQuery Tools Scrollable plugin.
Hey Chris
Always enjoy your posts.
FYI – I encountered a problem with responsive table approach on iOS 5.0.1 / mobile safari. When table had approx 40 rows safari would just shut down.
Android 2.x was fine.
I went on a few wild goose chases thinking it was scripting related but eventually tracked it down to the thead tr absolute with top/left -9999px. Took that out and set it to display:none and problem solved.
Hi ..
Just wanted to grab your attention to another interesting approach… (Not pure CSS though)
http://filamentgroup.com/lab/responsive_design_approach_for_complex_multicolumn_data_tables/
It’s a really great article !!! thanks for posting it!