The optimal solution, in my opinion, would be if you could specify a viewport width within a section of the site. The browser would then shrink that portion down and the user would see the full table, shrunk down to the width of the browser. The user can then magnify that area to see the data better.
Not sure if I'm making sense here. Also, I don't think this is technically possible right now.
Another option here would be to remove less important columns. "Payment #1" seems extraneous. "Period", assuming it is monthly in all cases, could be changed to an abbreviated month name (eg, "Feb"). Now you'd have 3 columns that probably still look okay.
As a general solution for a many-columned table on a small device, I disagree that showing the full table and letting me pinch zoom is a good solution. It's a poor user experience, and I appreciate the designer taking the time to think about what my most important needs are and catering my small screen experience to them.
This is exactly why OP's solution to this problem is not universally implemented. It's a good solution in a small set of circumstances, but is a terrible idea if you had good justification for the tabular view in the first place.
This is all well trodden ground in CSS and UX circles. Here's is the same solution (along with several others) from 2011: https://css-tricks.com/responsive-data-tables/
The main takeaway is that small screens just aren't good for certain things, like comparing large data sets.
So instead of “02/01/2015" and “01/01/2015 - 01/31/2015” use “2/1” and “1/1-31” … or even “Feb 1” and ”Jan 1-31”.
I assume that under payments they would normally have some other description other than “Payment #1”, “Payment 2”, etc. - otherwise that is a waste of space as well.
The original table's border is removed, and every tr is styled to look like a table by giving it a border. tds are turned into rows by setting display:block. The td rows are given row headers using pseudo elements, which pulls their content from an attribute on the corresponding td.
However, for tables showing genuinely tabular data, I'd almost always prefer to just see the original table and scroll horizontally, perhaps with appropriate heading columns or rows fixed so that they always display.
Does anyone have appropriate CSS that produces an effect similar to "position: fixed" but only for horizontal scrolling, not for vertical scrolling? Or only for vertical scrolling, with it scrolling off the screen when scrolling away the last row of the table?
Imagine the following as a large table:
| col1 | col2 | col3
row1 | d11 | d12 | d13
row2 | d21 | d22 | d23
row3 | d31 | d32 | d33
But I doubt one can do that with a table only, which is a shame, because it would lose markup semantic.
Edit: Little PoC http://codepen.io/anon/pen/LEoyrK
Yes, we use a variation of that theme as well.
It works to a useful degree, as long as you have enough control over the dimensions that you don't wind up with the row heights differing between the row headers table and the data rows table.
Of course the mark-up is semantically poor, but then HTML's enforced columns-inside-rows nesting for tables is already horrible to work with if you want to show a data record per column and use the row labels for the fields rather than vice versa, making any sort of templating system fragile as well. Rather like floats, this is one of those areas where no amount of CSS tweaks can now make up for underlying weaknesses in the spec of HTML itself.
Tables just aren't built to do that well in my opinion.
We could do better than what we have, though. Hopefully we will before too long, if position:sticky becomes standardised, complete with the notes about making it work properly in a tabular context where some other positioning explicitly isn't required to.
I'm not sure how effectively we'll be able to write a comprehensive polyfill without resorting to JS, so maybe we'll have to settle for gracefully degrading to having the entire table scroll without locking the row headers in place. At least the table mark-up will be more sensible than having two completely separate table elements with some sort of wrapper(s).
Data tables are hard in a corporate setting when mobile access is thrown in. It takes a lot of planning to determine the actual needs of users whose usage context puts them on a mobile phone or a tablet. Mobile <> in motion, and tablet <> on a couch. Oil rig operators may use a tablet to access production data, and so their tables would need larger targets for scrolling or toggling columns, and a larger/heavier font with higher contrast colors to be visible in harsh lighting conditions. Field sales reps may be using their phone while in the lobby before a sales meeting, and don't necessarily need just a subset of data.
Content may be king, but context is its queen.
He did this and added some reader submissions on other approaches.
We've been using this same technique in several projects where it seemed appropriate for the past few years and have been loving it.
The problem was that there is no way to reliably have the responsive styles kick in with CSS alone. You need to know how wide that table is on the page to know when it needs to respond. At his shortfall of CSS (and others) has driven me to create a CSS polyfill to add Element Query support to CSS so I finally can build tables that are responsive wherever they display. My plugin is available at http://elementqueries.com but I haven't had a chance to apply it to tables yet
When I make a responsive table I feel like turning every column into a distinct row makes it more difficult to navigate; instead I prefer to split the columns into groups and wrap them with alternate coloring. So if there are 5 columns maybe 3 go in the top of the row and 2 go in the bottom of the row (top and bottom sharing the same background color).
Is this kind of cols-to-rows substitution more user-friendly?
We didn't have the time to implement this in our app, but it looked great. I'd like to see how easy it is to integrate to use Bootstrap styles.
A while ago, I css-ed a table into a list for small displays, because lists seem "natural" to me on mobile than any crammed table. Not perfect but been using it ever since:
The people who are pointing out that this solution isn't "a more powerful responsive label scrolling spreadsheet" are right, but they're likely only after a faster horse.
As an aside, a table can have multiple tbodies according to HTML specs, so there's no need to use CSS generated elements to achieve the card styling in the demo. Just wrap each record into a tbody and style that.
I have a tiny jQuery plugin to stick a span inside a cell to form the heading at small sizes, but I like the data-attribute approach better. I think I'll change my plugin to do it this way now.
Related: Hey Travis and Will, nice work on this!
The best part is that I can choose which columns "hide" in whatever order I want, for however many breakpoints I want.
https://developer.mozilla.org/en-US/docs/Web/CSS/attr#Browse... goes back far enough that I'd be surprised if they'd drop a feature which has been around for such a long period of time or that the browsers vendors would do anything other than ignore the spec until it was corrected.
1) Maintainability. JS is probably easier to grok in some circumstances, ie. you don't have to send new devs to a blog post to explain the CSS on your project.
2) Cost/benefit analysis of dev time, ie. you could do X (where X is some minor display that 1% of your users see) in pure CSS in 12 hours, or do the same in 30 min of JS.
3) Cost/benefit analysis of page size, ie. you can do in 4 lines of JS what would take 400 lines of CSS. Sometimes a few lines of jQuery obviates several hundred lines of CSS (between the media queries, browser-specific overrides, and so forth).
The interesting question the article should address was why the CSS solution was a better choice than the JS solution. I have a gut feeling the answer is way better than "we just wanted CSS only for purity's sake", and personally I'm interested in knowing what that answer is!
My joke-solution (working only for fixed amount of rows, with fixed dimensions): multiplying the headers for each row with text-shadow.
He is using attr(data-label); to pull the titles from the data attributes and then uses Pseudo Elements to add the title to each td while displaying them in blocks. The end effect is very nice and requires no JS.