Live data from Hacker News

Making Tables Responsive with Minimal CSS

bradleytaunt.com

11–20 of 39 posts

Re: Making Tables Responsive with Minimal CSS

#11
post #6

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

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

Re: Making Tables Responsive with Minimal CSS

#12
post #2

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"; } ...

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

Thank you for taking my suggestion into account.

Re: Making Tables Responsive with Minimal CSS

#13
post #8
post #3

Earlier quoted context omitted.

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

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.

Re: Making Tables Responsive with Minimal CSS

#14
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.

Re: Making Tables Responsive with Minimal CSS

#16
post #6

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

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?)

Re: Making Tables Responsive with Minimal CSS

#17
post #2

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

Re: Making Tables Responsive with Minimal CSS

#20
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.

Post reply on HN