web-platform-tests / interop

web-platform-tests Interop project
https://wpt.fyi/interop
289 stars 28 forks source link

Responsive Tables #741

Open dsenneff opened 3 days ago

dsenneff commented 3 days ago

Description

Tables are among the most-common types of web content. Despite this, they don't fit well in the post-responsive design web. On wide screens they're easy to view and digest. But once the viewport narrows, especially on mobile devices, they can get problematic.

Problems

Table columns become smushed as they narrow, which causes odd text wrapping, line breaks, and otherwise makes content difficult to read.

In addition, tables reach a point where they force horizontal page overflow, breaking the site design and making users scroll the whole page back and forth to view it. This may also cause other page content to widen and require horizontal page scrolling to view it.

As a result, developers feel pressure to make tables "fit", and over-engineer solutions that cause additional issues. One common practice is to re-layout the tables into stacked blocks via media queries. This has its own issues:

Developers may also hide columns or even the entire table as the viewport narrows. This removes content for some users and not others, causing unequal experiences.

Third-party JavaScript libraries may also be leveraged to do things like make collapsible columns and rows, swap tables out for charts and graphics, and other unnecessary "corrections".

If data tables were more responsive-friendly out-of-the-box, users could consume them easier than they can today. Developers also wouldn’t have to do additional work making them accessible or feel pressure to make unnecessary modifications.

Workaround

The current best-practice workaround to make a normal responsive table is to wrap a div element around the table. The wrapper then gets an overflow property to make it scrollable while keeping the table’s natural width. This works, but the wrapper isn’t accessible.

To make it so, the wrapper needs to be given a tabindex attribute so it can be navigated to and scrolled via keyboard and CSS focus styles so it can be recognized once keyboard users land on it.

The wrapper also doesn’t have any sort of accessible name or role, so screen reader users won’t know what it is. So developers also need to add these, often in the form of the role and aria-labelledby ARIA attributes. Most don’t go above and beyond by doing all of these things.

Solution

The table element should be natively scrollable without the need for a wrapping element. Developers should be able to set the overflow property directly on a table, which would allow it to scroll as needed based on the viewport and/or any width or height properties. The table's cells can then remain an appropriate size without squishing and making the content unreadable.

Scrollable tables should also be keyboard-accessible without needing a tabindex attribute. A scrollable table would receive the user agent focus styles, which developers can override if they wish.

Because the table element has a defined role and can already be named via its caption (among other methods), developers would not need to manually add ARIA attributes to provide this information to screen reader users who encounter it.

Developers can still choose to use other methods if they wish, but the base experience is now much simpler and nicer.

I couldn't find anything in the HTML or CSS table specs that mentions scrollable tables. I'm not proposing any sort of new properties or elements. Simply that browsers utilize existing properties to modernize how they display and render tables in certain conditions. This would simplify development while simultaneously making web content accessible and easier to view for users.

Specification

https://drafts.csswg.org/css-tables-3/

Additional Signals

No response

bkardell commented 2 hours ago

Just to clarify: Is there an existing aspect of a standard which is not currently (or correctly/consistently) implemented in 1 or more browsers? Something testable with WPT,ideally? Or is this (as I think I understand) a request for a common, but not currently specified UA default treatment?

dsenneff commented 1 hour ago

Moreso the latter: a request to figure out a better, unified way for user agents to display tables, either by default or some sort of opt-in (in my proposal, adding the overflow CSS property to one).

I don't believe any standard broaches the topic of a responsive-friendly, scrollable table, so I wasn't sure where this proposal/idea would be best posted for discussion. The CSS Tables spec only mentions that the overflow property on a table should be ignored, and the CSS Overflow spec doesn't even mention tables specifically.

Maybe this was better posted as an Interop investigative proposal rather than a focus area proposal? I guess the functionality isn't defined anyplace so there wouldn't be a test for it. Or maybe it's something to bounce to the CSS Working Group first to iron out the practicality and rules for something like this?