Table sticky-header width causing overlap

Created on 24 November 2022, about 2 years ago
Updated 31 January 2023, almost 2 years ago

Problem/Motivation

When table header is longer than page length with longer titles, the sticky header isnt responsive and when triggered covers the rest of the table.
see attached

Steps to reproduce

Go to the Webform results page, that has at least 20 responses and 10+ columns for form fields and begin to scroll

πŸ› Bug report
Status

Needs work

Version

3.0

Component

Code

Created by

πŸ‡¦πŸ‡ΊAustralia brookeh

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡©πŸ‡ͺGermany berliner

    Setting the table to `width: auto;` seems to fix it for me.

    In the rc, the width calculation doesn't happen on the full table, but on the individual columns instead. This has been done in πŸ“Œ [JS Refactor] tableselect / tableheader Fixed .

    From what I can see, also using Horizontal, Modern Toolbar (though no idea if related or not), the table inherits `width: 100%` from claro, which makes it span too wide. Setting that to `width: auto` (via `table.sticky-header { width: auto; }` constraints the table to the cumulative width of the (correctly calculated) column widths.

  • πŸ‡ΊπŸ‡ΈUnited States tea.time

    @berliner oh my gosh THANK YOU - this has been driving me bonkers on views with many columns in a table, and that bit of CSS seems to work for me too.

  • πŸ‡ΊπŸ‡ΈUnited States tea.time

    Actually... I've discovered that table.sticky-header { width: auto; } unfortunately doesn't handle the case of the table wider than the page.

    The table is inside a wrapper with horizontal scroll (div.gin-table-scroll-wrapper), so if it's too wide, it'll scroll horizontally. However, the sticky header does not horizontally scroll with it, so the column headings don't stay aligned. :(

  • πŸ‡©πŸ‡ͺGermany berliner

    @tea.time Outch, good catch. It's true, I didn't test that scenario at all, just wanted to get rid of the overflow quickly. Too quickly ..

  • @saschaeggi opened merge request.
  • Status changed to Needs review almost 2 years ago
  • πŸ‡¨πŸ‡­Switzerland saschaeggi Zurich

    This change needs a review

  • πŸ‡©πŸ‡ͺGermany berliner

    Thanks @saschaeggi. That change works for me without the width: auto; on the table and fixes the issue.
    I couldn't test the scenario described by @tea.time though.

  • πŸ‡¨πŸ‡­Switzerland saschaeggi Zurich

    @tea.time can you have a look at the MR and report if it fixes the problem for you as well? TY

  • Status changed to Fixed almost 2 years ago
  • πŸ‡¨πŸ‡­Switzerland saschaeggi Zurich

    Thanks y’all

  • πŸ‡¨πŸ‡­Switzerland danielwirz

    @abelass, yes, that might be true. there are several issues covering the same problem, so i wasn't really sure where to put it. sorry, if picked the wrong one.

  • @edwardsay opened merge request.
  • Automatically closed - issue fixed for 2 weeks with no activity.

  • Status changed to Fixed 11 months ago
  • πŸ‡©πŸ‡ͺGermany berliner

    This overflow issue somehow appeared again in rc8 on D 10.2. I didn't have time to investigate further at the moment, but the "table { width: 100% }" fix worked in my use case again, ignoring issues with table overflowing the page content horizontally.

  • πŸ‡»πŸ‡³Vietnam mrddthi

    Anyone here can reopen the issue?

Production build 0.71.5 2024