Changing the table format from rows to "cards" is an ABSOLUTELY TERRIBLE solution. I don't understand why people do this. It's not a table anymore. You can't easily compare the figures in the columns against each other. 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,…
If you are using a phone you are probably not doing some heavy math with row comparisons.
Responsive Tables in Pure CSS
61–70 of 74 posts
Re: Responsive Tables in Pure CSS
#62This indeed transforms information about a group of records from a tabular spreadsheet into individual card representations. 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…
So if you have say 100+ records in a table you will end up with 100+ extra and tags? Just to style it for mobile? I don't think its a good solution
Re: Responsive Tables in Pure CSS
#63Earlier quoted context omitted.
Why add JS if it isn't necessary?
That's a pretty trite response. I can think of a few reasons: 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 o…
Re: Responsive Tables in Pure CSS
#64Re: Responsive Tables in Pure CSS
#65Re: Responsive Tables in Pure CSS
#66This indeed transforms information about a group of records from a tabular spreadsheet into individual card representations. 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…
So if you have say 100+ records in a table you will end up with 100+ extra and tags? Just to style it for mobile? I don't think its a good solution
Re: Responsive Tables in Pure CSS
#67Earlier quoted context omitted.
Yes, it can be easily done with a combination of divs, fixed width and overflow-x: scroll. 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
Nearly every solution for this I have seen or implemented uses a combination of 2 divs with tables inside to work the scrolling. Tables just aren't built to do that well in my opinion.
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).
Re: Responsive Tables in Pure CSS
#68Earlier quoted context omitted.
Yup, though the different way to do it with data- attributes and no content in the stylesheet was also written about here [1] in 2012, and demo'd here [2] at the bottom of the page in the "No more tables" example. We've been using this same technique in several projects where it seemed appropriate for the past few years and have been loving it. [1] https://css-tricks.com/responsive-data-table-roundup/ [2] http://elve…
Yeah, I presumed I wasn't the first under the sun to do it; just thought it would be interesting to write about since some of my fellow front-enders hadn't seen the technique and google didn't turn up either of those links :)
Re: Responsive Tables in Pure CSS
#69Changing the table format from rows to "cards" is an ABSOLUTELY TERRIBLE solution. I don't understand why people do this. It's not a table anymore. You can't easily compare the figures in the columns against each other. 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,…
Re: Responsive Tables in Pure CSS
#70My joke-solution (working only for fixed amount of rows, with fixed dimensions): multiplying the headers for each row with text-shadow.