People scrolls sideways at every width, and a third of it is four buttons #91

Closed
opened 2026-09-07 14:55:06 +00:00 by tiagoagueda · 0 comments
Owner

Observation

user list obliges to a horizontal scrolling to see all user details: propose ways to
avoid horizontal scrolling

Measured, in a browser, before proposing anything

Server settings -> People, five accounts, Chromium:

Viewport Card Table Overflow
1440 760px 967px 207px
1280 760px 967px 207px
1024 728px 967px 239px
768 736px 967px 231px

It scrolls at every width, including a 1440-pixel desktop. This is not the narrow-screen
problem it looks like: the settings area gives the card about 730 pixels whatever the window
does, so a wider monitor never helps. Anybody who has opened this page has scrolled it.

Where the 967 goes:

Column Width
Username 150px
Name 99px
Email 197px
Last sign-in 66px
Role 120px
Actions 335px

The actions column is more than a third of the table and larger than Email, and it holds
no information at all -- it is four buttons with their labels spelled out end to end: Change
username
, Make administrator, Deactivate, Delete account.

The fix

The actions become one menu. The same <details data-menu> disclosure the account menu
in the header already uses, so it opens on a keyboard without help and the existing script
only adds "close when the pointer goes elsewhere". Every action is still there and still a
word; the words are inside the menu rather than laid across the row.

That takes the column from 335px to about 44, and the table from 967 to 676 -- which fits
the 728-pixel card with room left, at every width in the table above. Verified in the
browser rather than calculated: scrollWidth - clientWidth is 0 at 1440, 1024 and 768.

And below the md breakpoint the rows become cards. 676 pixels still does not fit a
390-pixel phone, and five columns have nowhere to go there. A new table-cards component
turns each row into a card with its cells stacked, each labelled with the column it came
from.

That technique works by making table elements blocks, and doing so strips the table
semantics a screen reader navigates by
-- "Administrator" stops being the Role of a row and
becomes a loose word. So every element carries its ARIA role explicitly. On a wide screen
those roles are exactly what the elements already are and change nothing; on a narrow one
they are the only thing holding the meaning together. There is a test for it.

Deliberately not done

The other eight tables. Every table in the interface is wrapped in overflow-x-auto, so
others may well overflow too -- Invitations, Applications, Listings, Companies, Rendered
documents, Logs, Plugins, the CSV mapper. table-cards is written to be reused by them, but
nothing else is touched here and none of them has been measured. Worth its own issue.

A backdrop under the open menu. An open menu covers the next row's button, and this
looked at first like a misclick hazard on actions that take effect at once. It is not: the
panel is visible, and a person does not click a control they cannot see. Adding a backdrop
would also have changed how the header's menu behaves, which is not this issue's business.

Classification

Bug, interface, accessibility. Cosmetic in consequence and constant in effect: this is the
page an administrator uses to do anything about anybody.

## Observation > user list obliges to a horizontal scrolling to see all user details: propose ways to > avoid horizontal scrolling ## Measured, in a browser, before proposing anything Server settings -> People, five accounts, Chromium: | Viewport | Card | Table | Overflow | | --- | --- | --- | --- | | 1440 | 760px | 967px | **207px** | | 1280 | 760px | 967px | **207px** | | 1024 | 728px | 967px | **239px** | | 768 | 736px | 967px | **231px** | **It scrolls at every width, including a 1440-pixel desktop.** This is not the narrow-screen problem it looks like: the settings area gives the card about 730 pixels whatever the window does, so a wider monitor never helps. Anybody who has opened this page has scrolled it. Where the 967 goes: | Column | Width | | --- | --- | | Username | 150px | | Name | 99px | | Email | 197px | | Last sign-in | 66px | | Role | 120px | | **Actions** | **335px** | The actions column is **more than a third of the table and larger than Email**, and it holds no information at all -- it is four buttons with their labels spelled out end to end: *Change username*, *Make administrator*, *Deactivate*, *Delete account*. ## The fix **The actions become one menu.** The same `<details data-menu>` disclosure the account menu in the header already uses, so it opens on a keyboard without help and the existing script only adds "close when the pointer goes elsewhere". Every action is still there and still a word; the words are inside the menu rather than laid across the row. That takes the column from 335px to about 44, and the table from 967 to 676 -- which fits the 728-pixel card with room left, at every width in the table above. Verified in the browser rather than calculated: `scrollWidth - clientWidth` is 0 at 1440, 1024 and 768. **And below the `md` breakpoint the rows become cards.** 676 pixels still does not fit a 390-pixel phone, and five columns have nowhere to go there. A new `table-cards` component turns each row into a card with its cells stacked, each labelled with the column it came from. That technique works by making table elements blocks, and doing so **strips the table semantics a screen reader navigates by** -- "Administrator" stops being the Role of a row and becomes a loose word. So every element carries its ARIA role explicitly. On a wide screen those roles are exactly what the elements already are and change nothing; on a narrow one they are the only thing holding the meaning together. There is a test for it. ## Deliberately not done **The other eight tables.** Every table in the interface is wrapped in `overflow-x-auto`, so others may well overflow too -- Invitations, Applications, Listings, Companies, Rendered documents, Logs, Plugins, the CSV mapper. `table-cards` is written to be reused by them, but nothing else is touched here and none of them has been measured. Worth its own issue. **A backdrop under the open menu.** An open menu covers the next row's button, and this looked at first like a misclick hazard on actions that take effect at once. It is not: the panel is visible, and a person does not click a control they cannot see. Adding a backdrop would also have changed how the header's menu behaves, which is not this issue's business. ## Classification Bug, interface, accessibility. Cosmetic in consequence and constant in effect: this is the page an administrator uses to do anything about anybody.
tiagoagueda added this to the 0.3.0 milestone 2026-09-07 14:55:06 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Postulo/postulo#91
No description provided.