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.
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.
Also, Jason Grigsby has an article on choosing a solution based on what the user would want to do with the table.
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.
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.
Hope this helps out!
i ve try your ide but it shor very rare in my website… huuufhh.. look http://lintas5.com/
+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.
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    … 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.
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.
Setting it to display:none will hide it from screen readers.
There are different techniques to hide elements visually while ensuring they’re accessible on all devices.
With Chris’s technique, Safari might suffer in performance because of the viewport. Safari, at the time of your writing, relied heavily on elements using absolute positioning. Try targeting mobile with a smaller percentage. Try -100em (Stop using pixels! It’s not 2003) and see if the performance increases.
Just wanted to grab your attention to another interesting approach… (Not pure CSS though)
It’s a really great article !!! thanks for posting it!
The Zurb implementation is specifically great for tablets and small desktop resolutions. However, their code isn’t optimized. They’re querying two pseudo selectors in jQuery. That’s a big no-no. (No offense, you guys).
I’m a little rusty with my jQuery, but I can speed up the code by limiting one of the pseudo selectors to render as native JS:
copy.find('td:not(:first-child), th:not(:first-child)').css('display', 'none').addClass('hidden visuallyhidden');
copy.find('td, th').not(':first-child').css('display','none').addClass('hidden visuallyhidden');
Again, I’m rusty with my jQuery, but what you want/need is something like $var.find(‘td,th’).not().first()….. or first().not()… whatever…
Someone else can probably chime in.
As a rule of thumb, using pseudo selectors in jQuery are convenient, but your mileage will suffer tremendously.
I Love this article! I think that this area needs a lot of research, for example, the idea of being able to turn on additional table columns is a great idea, but I would like to offer a demo (Proof of Concept only) for anyone with the time to expand upon to do so. It uses your table column hovering concept and works from modern smart-Phone (using 4s as a base-line), iPads and PC’s.
Bad things are
Uses fixed positioning
Needs Additional Control logic to prevent display / usability errors / issues
On small devices looks huge
All data available at all times no matter the form factor
Uses Vertical Navigation with Horizontal aspect
Allows for base / main-column
mainly CSS (just under 25lines of jQuery in PoC)
no !important used so you can enforce your own view
supports common tabular elements such as togglable banding, hover effects at row and column level and headings (footers being trivial to implement alongside)
Good post! Lots of clever ideas. I feel there’s a notable lack of simple, pragmatic solutions, though.
After reading, I slapped this together:
Fewer than 20 lines of CSS
Interesting, but it doesn’t work in IE9. Truly responsive design should be backwards-compatible, as well as working well on on mobile devices. But I do like the horizontal scroll, like Kelly Cook’s example below. (Which works in IE9 even in compatibility mode, Kelly. Well done!) I think a combination of yours and Kelly’s, along with Maggie’s concept of allowig a user to turn columns on and off so the user can focus on the exact data they need at that time may be the best way to go. Now we could only find a working example that merges those techniques as well as being web accessible, I think we’d have a real winner.
Thank you for this article. After trying every solution presented, I still was not happy with the results. I decided to create a mashup of my favorite parts of the solutions above and came up with this: http://kellycook.github.io/responsive-tables/.
It uses your original solution, but instead of using CSS to display the faux table headers, I used Mobifreak’s data-label concept. I then added a wrapper around the table and gave it an overflow: auto so that lte IE9 browsers get a horizontal scroll. Thanks again!!
This goes to the heart of my search for answers to the ‘device-agnostic’ approach to web: how do we answer design and usability questions like this while responding to the largest percentage of users’ needs? I suppose validation for each project would allow developers and designers to make educated decisions but we don’t always have this luxury. How does everyone else decide between these options?
I was very difficult to make a responsive table that can be viewed from all devices, whether this tutorial can be used for templates blogger, because I use the standard template of blogger