Handling admin pages with tables

This is a terrible idea. There is no such thing as "not mobile content". If you want to hide this from small viewports, ask the following question: do we really need it for the large viewports. If we need it for large viewports, we should not hide it just because someone is on a smaller viewports. There are a plethora of responsive table solutions, we should implement one of them (or come up with our own) before we start willy-nilly hiding columns for small viewports.

This is the direction that has already been implemented in core. See the patch commited #1276908: Administrative tables are too wide for smaller screens

Here's a issue to unify code for draggable admin listings #1855402: Add generic weighting (tabledrag) support for config entities (ConfigEntityListController)

An approach similar to the resolution detailed above needs to be adopted for admin/config/regional/date-time to retain retain first & last column in narrow screens.

We can try to hide extra data in the existing tables that Drupal core produces in the Admin UI, but let's not forget that Drupal is built to be extensible.

If a site builder creates a table View for administrators, to replace or augment an existing admin page like /admin/content/content, and the Seven theme's layout completely *breaks* on this page, is it the sitebuilder's fault? IMHO, it's the theme's responsibility to support the fundamental issue of too much data in a row (or header) to fit into a narrow screen.

The obvious solution for this scenario is to add a wrapper around the view table, that denotes that the view is a table layout (this currently doesn't exist), and use overflow-y: scroll; on that wrapper. Then you come to the problem of keeping sticky headers in sync as you scroll horizontally. -- for me the solution here is also easy: simply don't allow sticky headers when the table header width is wider than the viewport width.

Thoughts?

Let's work with the assumption that not every admin table will become a view. Let's finish implementing what we started in #1276908: Administrative tables are too wide for smaller screens

The obvious solution for this scenario is to add a wrapper around the view table, that denotes that the view is a table layout (this currently doesn't exist), and use overflow-y: scroll; on that wrapper.

Sadly that is not an adequate solution either, testing showed that it's incredibly difficult to keep track of which row is the one you want when scrolling horizontally.

Related #1876712: [meta] Convert form tables in core to new #type 'table'

Related: #1975352: Webkit select element can push table wider than viewport