I like the idea behind this article, but "Responsive Tables #2: Flexbox" really is a pretty good example of what _not_ to do.

Just hiding the table header definitely does not work - this is how I first "read" the data:

- Slice of Pizza = 450

- 95% = $5.00

- Common = 8/10

And this clearly doesn't make any sense at all.

PS: I would love to see Markdown formatting make it to HN comments one day...

The CodePen "Responsive Table 2.5" further builds on that example and tackles that exact problem you mention (by including the heading of what each cell represents)

If you're putting the heading in each cell, it kind of defeats the purpose of using a table to begin with, no? If I was so painted into a corner by mobile support and refused to make scrolling friendly (e.g., by pinning the left column), it sounds like just not using a table in the first place is a much better solution.

Inheriting this kind of functionality with just a little bit of CSS is pretty dang convenient though and a pretty sensible default, if nothing else.

Yes, not using tables is the best solution for mobile support.

But sometimes you can't do without. Then it's nice to know your options.

> PS: I would love to see Markdown formatting make it to HN comments one day...

Sadly, properly formatted comments don't bring paulg joy.

Remove the borders and background shading from that example and it will read just fine as a set of attributes

Yes, but these are not attributes. (Or was that your point?)

There are other approaches which avoid the repetition of column names in SPAN chunks as suggested in the article.

The most elegant and least bandwidth consuming one is described in https://css-tricks.com/responsive-data-tables/ and uses modern CSS selectors:

   td:nth-of-type(1):before { content: "Type of Food"; }
   td:nth-of-type(2):before { content: "Calories"; }
   td:nth-of-type(3):before { content: "Tasty Factor"; }
   ...

That's really not ideal. That is putting hardcoded data in CSS.

You could move the data into a data attribute, and then use "content: attr(data-td)" for example.

Doesn't that take the problem back to the spot where we have the header repeated for each cell? In a data attribute instead of a span, which may be cleaner, but still:

https://codepen.io/andrelaszlo/pen/xoxmdg

Is there a way to only define the header label once and refer to them depending on the cell using only CSS?

you may use html template engine

can be circumvented by binding the header row & the styles to the same data, but gets complicated when you have cells in the header or body which span rows or columns, or have row-scoped headers.

There's a ton of information in the CSS already - anything that uses color to denote meaning, or the layout of a component, or the order of items in a flex list, and so on. That's all data in a page's information hierarchy. Plus, the content attribute of the ::before and ::after pseudoelements literally exists for injecting content in to a page using CSS. Why not use it?

Imho, labels in the CSS are pretty tricky for i18n. The colors doesn't (generally), need traductions, they have the same meaning whatever the language. Data attributes in another hand, despite of being a bit redondant (in fact, it's not that insane in a loop ^^'), can be easily translated in HTML.

Thanks for the additional option - I've updated the article to include that possibility as well

Thank you for taking my suggestion into account.

That article was written in 2011. I would've hoped we would have a more elegant solution in the intervening years. Data tables are widespread, the need for responsive design is well-known, why is there not a general solution already baked into CSS?

How do we still not have fixed column and row headers with horizontal and vertical scrolling? Almost every business website I've ever worked on wants it. Someone remakes it for every framework as soon as they come out.

you can use `position: sticky`[0] for that, but the last time I tried it table support was spotty. That was back in 2012 though, so I imagine that things have improved since then.

[0] https://developer.mozilla.org/en-US/docs/Web/CSS/position

LOL I've got the old ones covered https://github.com/kingkool68/stickyHeader

The author suggests that this approach is good for accessibility, but historically assistive tech has struggled with tables that aren’t their native display:table. I’m not saying that this is the case here, but I’d be wary about making that claim without testing with at least JAWS and VoiceOver.

CSS Grid to the rescue!

First up, style for desktop so you know what the full table should look like.

Then look at the table with your data in it. Try it on mobile and check the usability. Maybe there are supplemental columns that you have put in because you have the data but are not so important to the person on the move.

In this scenario you can make it so that a click on a table entry brings up the whole record. This could be on a separate page or in a pop-up. Again, depending on the data and the intended audience this has to be worked out by a little bit of prototyping. In the mix are font sizes and options to all 'and'hellip; to selected wide cells that can be abbreviated.

Now the fun begins in creating the responsive layout.

For the grid definitions - grid-column-rows - the desktop layout can be replaced with a CSS variable. In the CSS variable a fallback of the desktop definition can be given. This should be there already. For the variable definition that goes in a media query. This media query can be set to the max-width that best suits the data, if the table looks good down to 40 ems then the media query can be for that and below.

This approach makes it easier for the next guy that comes along. They will only have to know CSS Grid and not any of the Byzantine methods of page layout that came before CSS Grid.

This should degrade gracefully to a stock table for anyone with an extremely old browser.

I'd love to see a codepen/jsfiddle/gist/whatever that builds out what you describe so it can be compared to the examples on the article?

If you want to give it a go then this is all you need to know to get started...

So your starting grid is on the table element - display: grid; grid-template-columns: (depends on your column data, start with '1fr auto auto auto...' with as many autos as you need for your data.

Then you need to add display:contents on thead, tbody and tr.

If you are using a caption then set that to grid-column: 1 / -1;

Your original grid-template-columns for the table can then be modified to suit your data, use 1fr to keep things the same width, 2fr if you want a double standard width column.

Then you will need to turn the grid-template-columns definition into a CSS variable, with your desktop layout in the fallback and the variable set by a media query for the responsive view.

Give it a go, once you have done it once you will wonder why you did it any other way.

There are other things you can do to make a sparse table with some cells taking up multiple rows or columns on an ad-hoc basis.

Really, once you have the display:contents trick working for you nicely there is nothing to write a codepen about!

I 2nd the request for jsfiddle / codepen for comparison. Not a css grid expert here - haven't had great luck with css grid responsive design without a bunch of media queries.

Are you using variable size fonts? Or are you having to do the paint by numbers thing with a design handed down to you?

So much of CSS grid is challenging to the ways pages have been written. Try getting desktop to work and then using CSS variables defined in your media queries so you only have the one set of CSS rules, with just the bits that change in the media queries.

This way is much more succinct and you know what bits change as those are the bits with the variables in them.

I recommend that you just give it a go on tables, next time you need to. I think it just needs judicious use of display:contents on the header and rows for it to fall into place. That and the CSS variables approach should get you there and the problem can be solved in a two step process.

I would not dream of styling up a table or anything else that needs to be in rows/columns any other way, previous approaches have been too fragile for me.

My favorite part of this compared to Pylon tool on front page today: "Why should I care to use table elements? Simply put: accessibility and proper semantics."

Accessibility for the win without extra workarounds.

My pragmatic way is to make one design/markup for small screens and one for big screens, and toggle the visibility of those two with media queries.

Often we want a completely different layout for mobile, and to focus on different data. Shoehorning the same markup for both cases just makes it harder to work with.

This site has many bite-sized but intriguing pieces like TFA. Kudos to the author for writing interesting things without any fluff!

Ironically, none of the example tables scroll on my iPhone (could be caused by the CodePen container to be fair).

It’s the embedded codepen container. Going to codepen itself lets you scroll.

Filament Group has Tablesaw which is another take on this idea. Javascript based but I think the results are a bit better https://www.filamentgroup.com/lab/tablesaw.html

Not quite about tables, but I feel this goes into the same direction and complements: https://dev.to/winduptoy/a-javascript-free-frontend-2d3e

One note: in demo 2, visibility: hidden will make screen readers ignore the headings.