Several admin pages with tables on them have enormous white gap on side on mobile

This is tricky, we are kind of running out of “non-essential” columns to remove on mobile. At least for the content listing page.

Could we re-format the table somehow? Let's say; put label and machine name on one row and rest for second row?

Not really. Early on we tried the idea of using a <ul><li> styled as tables to replace all responsive tables and we'd be able to make that work. We didn't go with that (don't remember the details, it's in a monter issue somewhere) so I don't know how we can solve this beside messy and slow javascript.

What would the slow & messy javascript approach be? Other options:

- Hide more "essential" columns. I'll assume that there's been discussion about why 'machine name' is essential, but in the end, the label and its operations are the two bare minimum ones, no?
- Revisit the ul/li approach (sounds like no fun) Anybody got a link?

Yeah, in the end, dropping more columns will not be the best approach. I asked Lewis to chime in.

#1276908: Administrative tables are too wide for smaller screens

We don't have another method for resizing tables on smaller screen. For now I think we should just hide more columns. This is not ideal but until we have a better method then it's better than what we have now

I've created: #2280035: Add another responsive tables solution that doesn't hide content

I had a quick chat with webchick about this and we agreed that as long as the first and last column are there we're good enough: the first colum identifies the thing, the last column exposes what you can do with it.

Updated the remaining tasks

Taking this one on.

Answer determined privately.

Attached patch adds the table responsiveness classes to views mentioned in issue.

Here're two pictures of both pages looking much better on mobile:

Attaching one more picture where I have created some fields with very long labels.

+++ b/core/modules/node/config/install/views.view.content.yml
@@ -557,6 +557,7 @@ label: Content
+uuid: 639bf094-2430-450f-8800-bec5a4e514e1

I don't think this should be in the patch?

As I see in the comments, the last patch does not resolve all the problems. Soo it needs work. Also this seems to me confusing enough not to be a novice issue (so removed that tag too).

I think for this issue we should just go with a gut feel and hide the ones we think are not required. It's easier to see in code rather than discuss it.

If there are any tables where it's impossible to hide enough columns to fix on the screen. We postpone them to a separate issue.

Evaluating during Friday sprint in Barcelona

The patch in #26 needs reroll against dev. The screens still have the same problem.

I did a 'special' reroll.

The file FieldOverview.php doesn't exist anymore, and the scope of the change cannot apply. This change, changes some code in buildForm. Now is done in buildHeader, and in all buildHeader function in fiuld_ui module is changed.

So, for this reason, I didn't add this change in the patch:

-        $this->t('Field type'),
+        array(
+          'data' => $this->t('Field type'),
+          'class' => array(RESPONSIVE_PRIORITY_MEDIUM),
+        ),

Corrected patch #31 to pass tests.

The patch #34 passes, but there are some work to do:

Already corrected tables:

• admin/structure/comment -> corrected
• admin/structure/contact -> corrected
• admin/structure/views -> corrected

Still needs correction tables:

• admin/content
• admin/structure/types/manage/[content_type]/fields
• admin/config/content/formats
• admin/config/search/pages
• admin/config/search/path
• admin/config/regional/date-time
• admin/people
• admin/people/permissions
• admin/reports/status
• admin/reports/views-plugins

As we can see tables are not responsive. As an alternative or additional solution for the problem could be adding overflow-x: auto for .page-content to make it scroll if it not fits the screen. In this case only content will have horizontal scroll, but not the whole page. And it looks better and more usable. See screenshots attached.
We can continue to hide low priority columns, but other tables could also appear with important columns and we will still have a problem. So my proposition could be additional to hiding columns for known tables.

How do you like the idea?

I think we need to add responsive classes for all core's tables and use #39 suggestion for tables that wide

Review intermediate fix and continue hiding columns for default tables.

this is a proposed solution to avoid break the mobile layout without add new js, just allow the browser to add a horizontal scroll if the content it's to wide.

+++ b/core/themes/seven/css/layout/layout.css
@@ -4,3 +4,10 @@
+ * Avoid break mobile layout adding horizontal scroll for wider content (tables)

Comments should (noramlly) begin with a capital letter and end with a full stop / period .

Fixed and attached new patch.

Currently in 8.4-dev the white space is not immediately visible upon page load in mobile, but still seen when scrolling to the right of long tables like admin/content. It's not clear from discussion whether this accomplishes the parent issue's goal of "look[ing] good in all browsers".

The patch in #47 applies but does not seem to change behavior from the base 8.4-dev install.

I am updating credit for the triage work. Going forward, you should know that we like to see documented triage steps (even if brief). It is the only way to know if the triage has actually been completed. Here are some made-up examples of documented triage steps:

• I tested the steps to reproduce and they did (or did not) work (so I am tagging it "Needs issue summary update").
• I searched for duplicate issues but could not find any.
• I checked the issue summary and it is accurate and up-to-date.
• Etc...

Thank you!

I've tested the patch in a minimised chrome window.

The patch fixes the problem by allowing to table to scroll horizontally.

Before:

After:

Unfortunately, the sticky headings don't scroll with the rest of the table. See video sticky.mov

Is this still an issue?

I used simplytestme to test this with Drupal 10.0.3. I enabled language and translations and installed Italian. I then browsed through the configuration pages including admin/structure/types as in #1 and the translation pages. I was not able to produce the problem of a 'white gap' of any size.

Therefore I closing this as outdated.