Responsive Tables in Pure CSS • Hacker News Board

Re: Responsive Tables in Pure CSS

#21

Post by wallawe » Mon, Apr 06, 2015, 4:38 PM UTC

im2w1l wrote: post #8

The article doesn't explain all tricks they use. A media query is used to apply the stylesheet selectively to small window sizes. That stylesheet splits the table into multiple ones. 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 cont…

Yeah, I wanted to focus on using pseudo elements to pull content in from data-attrs but obviously I could/should have gone into more detail on the other bits and pieces. Thanks for the suggestion.

Re: Responsive Tables in Pure CSS

#22

Post by JoshTriplett » Mon, Apr 06, 2015, 4:43 PM UTC

This seems like an impressive approach for data that uses a table for grouping but remains understandable when grouped linearly with duplicated labels.

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

Scrolling horizontally should keep the row labels visible, and scrolling vertically should leave the column labels visible until the last data row is scrolled off the screen. And ideally that should not require any JavaScript.

Re: Responsive Tables in Pure CSS

#23

Post by cms07 » Mon, Apr 06, 2015, 4:43 PM UTC

I hate it when web developers do things like this. The normal version of things is almost always better it seems.

Re: Responsive Tables in Pure CSS

#24

Post by Raphmedia » Mon, Apr 06, 2015, 4:45 PM UTC

fourstar wrote: post #14

A media query? Dang Living Social tearing up the engineering scene over here.

You missed the points.

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.

Re: Responsive Tables in Pure CSS

#25

Post by mxtopher » Mon, Apr 06, 2015, 4:48 PM UTC

JoshTriplett wrote: post #22

This seems like an impressive approach for data that uses a table for grouping but remains understandable when grouped linearly with duplicated labels. 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 e…

Hi there, take a look on position: sticky; It does exactly what you want. Please note it is still experimental though.

Re: Responsive Tables in Pure CSS

#26

Post by Domenic_S » Mon, Apr 06, 2015, 4:54 PM UTC

freshyill wrote: post #18

dfar1 wrote: post #11

Interesting read, but why no JS? Don't all mobile devices play well with JS? Is it a file size issue?

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 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!

Re: Responsive Tables in Pure CSS

#27

Post by telekid » Mon, Apr 06, 2015, 4:59 PM UTC

We've been using a similar technique over at untapt for a small table that display's past job applications:

Small version: http://i.imgur.com/sJOxCQw.png

Large version: http://i.imgur.com/xrJ4sBt.png

Re: Responsive Tables in Pure CSS

#28

Post by [deleted] » Mon, Apr 06, 2015, 4:59 PM UTC

[deleted]

Re: Responsive Tables in Pure CSS

#29

Post by jonahx » Mon, Apr 06, 2015, 5:06 PM UTC

nerdy wrote: post #15

First a disclaimer: I am a programmer, not a designer or UX specialist. 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 c…

An example would help answer definitively, but based on that description I don't think most people would find it intuitive. At a glance, it probably has a janky feel too. But I could be wrong.

Re: Responsive Tables in Pure CSS

#30

Post by psychometry » Mon, Apr 06, 2015, 5:10 PM UTC

JoshTriplett wrote: post #22

This seems like an impressive approach for data that uses a table for grouping but remains understandable when grouped linearly with duplicated labels. 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 e…

You can apply `position: fixed` to a `thead` element, but you need to either exactly specify or calculate (and recalculate on resize) all of the column widths in pxs.