Olivero does not support core's responsive tables API

Are we wanting tables to be stacked or stay in a tabular format in mobile view?

No. The best layout for a table depends on its content. There's no way for the theme to know this. So, we can't make assumptions and shift things around.

The best we could do is provide overflow containers, however this is somewhat weird. We'd have to use JavaScript to insert it before rendering, this has performance implications.

My thought is to leave as is. This is not an issue that can be solved for general use (although it can be solved for very specific use cases).

Thoughts?

@mherchel There is some initial work done on Table view overflow issue on mobile. Marked it as a duplicate to mark this as the main issue.

The best we could do is provide overflow containers, however this is somewhat weird. We'd have to use JavaScript to insert it before rendering, this has performance implications.

IMHO, overflow containers should work just fine following the Figna design and POC at https://www.drupal.org/project/olivero/issues/3093249

Are we wanting tables to be stacked or stay in a tabular format in mobile view?

The latter please! The point of tables is that they let you easily compare information by rows/columns. You lose this when stacking them.

The best layout for a table depends on its content. There's no way for the theme to know this. So, we can't make assumptions and shift things around.

We can make a fair assumption that if the author created a table, they considered the row/column relationships to be important. So it's preferable to keep the table layout.

Some approaches to responsive tables create a stacked presentation while preserving table semantics for assistive tech. However sighted users still lose the ability to easily use the row/column relationship.

My thought is to leave as is.

It's rather poor as is. On a small screen you get a slippy page which is hard to keep aligned when attempting to scroll vertically, especially with a touchscreen. It keeps slipping off to the side, into the whole-viewport horizontal overflow.

I recall seeing an early demo of Olivero which had a table inside a horizontally scrolling container. This would be much preferable.

The best we could do is provide overflow containers, however this is somewhat weird. We'd have to use JavaScript to insert it before rendering, this has performance implications.

Any idea how much of a performance impact?

For tables created with the "Table" render element, we could add a wrapper div server-side. Say with a theme_wrapper render property. That should cover Views and Forum module. It wouldn't help with table from the body text field though.

Related: does the core/drupal.tableresponsive library work with Olivero?

Note: the patch in #3192084: Table view overflow issue on mobile. made a scroll container by setting display: block; directly on a HTML table element. This removes the table semantics from the accessibility tree. This approach should NOT be committed without thorough assistive tech testing. Remember Firefox ESR and IE11 in this.

It looks like the table overflow style from the Olivero PoC has not been implemented yet. Once it's done, it should solve this issue.

We have column priorities for tables, so it's the responsibility of the module developer to implement those. This seems like it should be 'by design' to me (and possibly an issue opened against styleguide to use the responsive tables API if it's not already).

This is something currently happening in all themes. I'm not sure it's reasonable to expect Olivero to address this BUT.... This is addressed in an (at the moment RTBC) Claro issue which implements a solution very similar to the one in the Olivero PoC, but with additional logic to ensure sticky table header compatibility #3068696: Tables overflow on mobile. The plan with that Claro issue was to follow that up with a proposed change to core allowing a #scrollable property to table render arrays that would work in any theme.

So, to avoid too much duplication of work, it may be easiest to land that Claro issue then work on adapting that functionality to Core so Olivero can use it. Or, at the very least start this by copypasting (and changing where needed) what has already been done in Claro. The sticky header part was really tricky and nobody should have to re-discover how to address it 🙂.

I think this is probably a duplicate of #2280035: Add another responsive tables solution that doesn't hide content.

Actually no there's a more basic issue - Olivero doesn't support responsive tables at the moment at all. We should do that as a minimum step here I think.

@catch

Olivero doesn't support responsive tables at the moment at all. We should do that as a minimum step here I think.

That's referring to tables where columns can be toggled visible / hidden, such as at /admin/content and /admin/modules, correct?

If so, part of the problem appears to be that Olivero's table.css is missing the responsive table cells rules.

Adding this to Olivero's table.css makes the toggle button work at /admin/content:

/**
 * Responsive table cells.
 */
th.priority-low,
th.priority-medium,
td.priority-low,
td.priority-medium {
  display: none;
}

@media screen and (min-width: 38em) {
  th.priority-medium,
  td.priority-medium {
    display: table-cell;
  }
}

@media screen and (min-width: 60em) {
  th.priority-low,
  td.priority-low {
    display: table-cell;
  }
}

Also, at /admin/modules, that table.css file isn't on the page at all.

@kentr yes exactly this. Not sure why the library isn't added on admin/modules, although tbh I would make that a spin-off issue since Olivero-as-admin-theme is very niche anyway. However you can have user-facing tables on sites (a views member listing on groups could be in the front end theme for example).

Here's an MR to add support for Olivero, and before / after screenshots.

Though, long-term it might be better to move some of this to a central library and attach it in lib/Drupal/Core/Render/Element/Table.php where the JS library is attached. Specifically, I'm thinking of the changes to table.pcss.css.

Reasoning:

The JS drupal.tableresponsive library looks for those CSS rules to show the toggle button. For Claro they're in a general theme file for tables. It looks like Gin will also have them when it moves to core.

AFAICT, Umami doesn't support responsive tables either.

It looks like the rules are also loaded for pages that only have regular tables.

I'm thinking moving and conditionally adding them would DRY it out, make them available to all themes, and shave some bytes from the CSS when they're not needed.

Thanks for working on this!

Functionality looks great. Left some comments in the MR (stylistic changes for consistency)

Made some changes per the MR comments.

Bumping to the top of my list. Will look at this shortly!

This looks absolutely perfect! Thanks everyone!

Note: the media queries add the screen keyword: media screen and (--md) {. Olivero doesn't normally do this, but I think its appropriate here because if users want to print the content, they should get all columns.

Adjusted contribution credits.

Committed and pushed 20a3960 to main and 830165d and pushed to 11.x. Thanks!

Tested myself per reproduction steps, and here are screenshots after commit:
< 950px

> 950px