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.
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.
Here's some more that have cropped up:
Also Jason Grigsby has an article on choosing a solution based on what the user would want to do with the table.