[csswg-drafts] [css-content] Display contents of data table headers, footers, and captions using ::before and ::after (#5628)

JoshuaLindquist has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-content] Display contents of data table headers, footers, and captions using ::before and ::after ==
### Displaying data tables on small viewports
Styling data tables to be usable on small devices is a bit challenging. I'm not sure if there is really a common or "right" way to do it yet, but while researching solutions this week I repeatedly encountered articles explaining how to reformat the table into groups of data for small viewports.

Reference: [https://www.cssscript.com/pure-css-mobile-friendly-responsive-table/](https://www.cssscript.com/pure-css-mobile-friendly-responsive-table/)
Reference: [https://css-tricks.com/responsive-data-tables/](https://css-tricks.com/responsive-data-tables/)

It's easy to reformat the data table into a series of "data cards" by changing the value of `display`. However, it is still somewhat confusing to read through the data because the table headers are separated into their own group at the top of the table. This isn't the worst solution, but it requires the reader to remember the order of the headings while scrolling through the data (and if they are forgotten then it takes more time to scroll back up to read them again). 

You can get around this problem using generated content and `::before`. Some examples use a data-label attribute and `attr()` to display the values, and other examples just write the values directly in the CSS. It works, but it requires that you always know the contents of each `<th>` tag ahead of time. In my particular use case, I am working with a CMS and will never know the data ahead of time.

### Display the contents of each table headers using generated content
What I want to be able to do is take the contents of each <th> and insert it before each <td> in the CSS. That will make each set of data make more sense at a glance. Generated content was the solution that immediately came to mind. I thought that `content: contents` might have been the solution, but upon closer inspection, it's not quite right since I'm asking to display the contents of a different HTML tag than the one being styled. 

Spec: [https://drafts.csswg.org/css-content-3/#element-content](https://drafts.csswg.org/css-content-3/#element-content)

I suspect that I'm not the first person to consider using generated content to display anything from the document (perhaps using a class or id), but I can understand why that would be problematic in many ways.

Instead, I would like to suggest something more narrow. Can we use generated content to display data table contents (i.e. headers, footers, captions) within the scope of a single properly marked up table (i.e. it must have a `<thead>` and `<tbody>` for this to work properly)? I am personally wishing primarily to grab the table headers, but allowing the same options for other non-data cells would allow for more robust styling options.

### Alternatives
There are certainly other options for displaying tables on small viewports. For example, I can fix the height and width of the table and add scrollbars. Similarly, I've seen examples that turn the table on its side so that the headers are displayed down the left side of the page instead of horizontally, but horizontal scrolling is still required to view the data.

There are other more dramatic solutions as well, but they would only work in narrow use cases.

I haven't found an ideal solution. Some CMS may make this easier than mine (WordPress) with their templating options, and I am sure that I could build a plug-in that makes the tables work the way I am suggesting (and in the short-term, I may have to do that). I think a native CSS solution to this problem would be beneficial to anyone styling data tables since small viewports are increasingly more important.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5628 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 16 October 2020 17:56:04 UTC