Make <table> elements responsive automatically

[summercms]

Make <table> elements responsive to handle small screen devices on the x-axis.

There are poor hacks to make <table> elements responsive such as this:

https://www.w3schools.com/howto/tryit.asp?filename=tryhow_css_table_responsive

However, let's say we have a table with 100 rows and 25 columns on a single page.

7 out of 25 columns are only showing on a small screen device.

The user is viewing the table on a small screen device and half the table is hidden and hanging out of the right hand side of the screen.

A user scrolls down to row 50 of the 100 row table.

The user needs to scroll down to the bottom of the table to scroll the x-axis scroll bar to move the table right to see the missing right hand side data.

Then the user needs to navigate back up the page to row 50 to view the data.

This is a poor ux.

It would be better for <table> elements to be fully responsive and give better ux for people using the mouse or touch screen devices.

A better solution would be to allow users to grab the table at the desired row and be able to move the whole table, instead of needing to go down to the bottom of the web page and use the scroll bar.

This feature can be turned on and off by adding an attribute to the <table> element, maybe?

The attribute can control turning on the scrollbar and the grab function without the developer needing to wrap the <table> element with a <div> tag and adding extra css.

[HusienAdel]

@ayumi-cloud I don't agree with making tables responsive as a carousel to slide between, I think in another solution like making some columns are fixed, plus support hiding unnecessary columns, making a list to choose which column to view?

[una]

In regards to responsive tables, what about a right column with labels? While I do like responsive tables, I believe table behavior is relatively unique to the circumstance. Another example would be where one would have a smaller table that they'd want to stretch to fill a parent size. This overflow behavior is an option, not a default.

[gregwhitworth]

This was discussed during the most recent telecon:

una: this is about responsive table elements
... this issue has a bit more to it
... there is a proposition for making all tables responsive by making them scrollable
... I would love to hear what you all think
... some you may want to make them fit the space, and make them scroll

boazsender: does Open UI have a default opinion on responsiveness?

una: well, we stay away from really specific styling - we discuss behavior
... we do speak to UI but in this case it is the base usage of table; it falls under the bucket of core UI to an element

<una> gregwhitworth: we'd gone down this road IRT i18n and writing modes

<una> gregwhitworth: there was agreement that these are blueprints that we would implement including investigations for internationalization, boaz raises: do we want to add recommendations for responsive design and best practices?

<una> gregwhitworth: you then have to map your context and component structure to best practices, i.e. WICG best practices

<una> gregwhitworth: I'd prefer to stay away from it until there's the potential of a base stylesheet

<una> gregwhitworth: this one in particular, I don't know about. It would depend on body overflow. Technically all the layout of table is defined in CSS/HTML. We should discuss it here but its a good one to bring in other folks for

boazsender: at a conceptual level; what is our philosophy in specifying how the components/controls handle RWD, i18n is a good example
... brought up WICAG, and how it works with AT
... I would want to understand how we're going to define AT engagement

bkardell_: I wanted to say, the issue is not about what we're discussing
... the meta seems like a good issue for us to discuss
... maybe we end up with misses because we don't currently think about RWD
... if you want it to be open or collapsible, there are interesting things to talk about there
... tabs are another good example, which I'm interested in
... form factor is very important there
... I think boaz, is saying that that should be a meta issue

<scribe> ACTION: boazsender to open issue on meta RWD

una: I think it is important for us to talk about the behavior and how it changes on the form factors
... I think this does fall under that umbrella

<una> gregwhitworth: added an action to boazsender to add an issue for discussion. +1 what Una said RE: behavior, and we can still define behavior without that being a styling issue

<bkardell_> +1

<boazsender> +1

<una> gregwhitworth: I propose there's nothing to resolve on at this point but continue discussing this meta issue

<una> gregwhitworth: open issue on github to discuss level of scope IRT responsive web design and form factors

[cathibosco]

Adding this example of similar behavior in case it is useful. This is a solution we are currently using with Web Stories and we discussed looking at components behaving similarly ...
(I am new to contributing here so if this is not the right place to leave this please let me know, Thank you!)

Link to screenrecording: https://canddstudios.d.pr/Kc1BQd

[Malvoz]

@cathibosco That behavior can be enabled by CSS scroll snap (see carousel demo at CSS Tricks), but whether current table layouts can utilize scroll snapping well I haven't looked into, so I suppose that's a consideration for modern/responsive data tables.

[gregwhitworth]

@Malvoz yes, this can be achieved with scroll snapping, that said the original issue - and yours would be similar if we ever get around to defining a carasoul component is whether this behavior is defined given available container (not screen/viewport) real-estate. Thank you for the added example and your contribution was great!

[gregwhitworth]

Also, the issue for the meta discussion was opened here: #237

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

[LeaVerou]

Scrolling (and scroll snapping) works, but is rarely the optimal solution. More often than not when there's not enough horizontal space you want to include labels on each row and lay it out differently (e.g. top to bottom, or like a card etc).

Right now, while the laying out differently part is easy with CSS, there is no good way to get access to the column headers. All existing solutions are incredibly hacky and/or bloated. I'd love to explore ways to do this and give authors the primitives to make the styling decisions that best fit their use case.

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.