Five list and grid pages still sit in the 1280-pixel column: the report, tags, industries, an application's documents and the import mapping #273

New issue

Closed

opened 2026-09-18 10:12:46 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-09-18 10:12:46 +00:00

Owner

Measured rather than read: every signed-in page the accessibility suite visits (118 paths), opened in Chromium at 2560 pixels, with the width of <main> and the widest thing inside it recorded. Fifty-odd pages take the screen as #188 and #198 decided; every form, detail page and page of prose keeps its 1280-pixel measure, which is the rule those two issues wrote into base.html: a table, the board, the dashboard or a list empties the block and takes the screen; a form, a detail page or a paragraph keeps it, because a wide page is not a wide paragraph.

Five pages are lists or grids and keep the measure anyway. On a 1440p monitor each sits in a 1280-pixel column, and three of them cap themselves further inside it.

Page	Template	What it holds	`<main>` at 2560	Cap inside
`/applications/report/`	`applications/report.html`	four `lg:grid-cols-4` grids of figures, a two-column grid, and a table in `.scroll-x` in the weekly view	1280	—
`/applications/tags/`	`applications/tag_list.html`	a list of rows	1280	`max-w-2xl`, 672
`/jobs/industries/`	`jobs/industry_list.html`	a list of rows: code, name, counts, actions	1280	`max-w-2xl`, 672
`/documents/applications/<pk>/documents/`	`documents/application_documents.html`	three lists of rows	1280	`max-w-3xl`, 768
`/import/`, the mapping step	`core/import_csv_map.html`	two tables, one in `.scroll-x`	1280 (read, not measured: the suite cannot reach it)	`max-w-4xl`, 1024

The report is the dashboard's shape — the same four-column grids of figures — and the dashboard takes the screen. The import mapping is the #188 symptom exactly: a spreadsheet with a dozen columns previews in a box that scrolls sideways inside a 1024-pixel column inside a 1280-pixel column, on a screen twice that wide. Tags and industries are the two lists in Postulo that stayed at 672 pixels while every other list took the width, and Industries is the one #141 has been adding columns to.

Where the line is, for the pages this does not name

Kept at 1280 on purpose, per #188, and not filed as wrong here: every form; the application, company, posting, CV and letter pages; Your career (pinned as measured in tests/test_width.py); the career preview; and search results, which are a reading list. If the line should move — detail pages too, or everything — that is a change to the rule in base.html rather than a fix to these five, and worth its own issue.

Proposal

Empty main_width in the five templates and drop their inner max-w-* wrappers, keeping a measure only around any paragraph of prose inside (the import page's explanations, say), the way the settings frames did in #198.
Add the five to WIDE in tests/test_width.py, and the import mapping through a client that has a spreadsheet stashed.
So the next one is caught rather than surveyed: a check over the rendered markup of every page the coverage test knows (VISITED_URL_NAMES) that a page holding a <table> or a grid-cols grid inside <main> has emptied main_width. The lists of plain rows would still need naming by hand; the tables and grids would not.

Measured rather than read: every signed-in page the accessibility suite visits (118 paths), opened in Chromium at 2560 pixels, with the width of `<main>` and the widest thing inside it recorded. Fifty-odd pages take the screen as #188 and #198 decided; every form, detail page and page of prose keeps its 1280-pixel measure, which is the rule those two issues wrote into `base.html`: *a table, the board, the dashboard or a list empties the block and takes the screen; a form, a detail page or a paragraph keeps it, because a wide page is not a wide paragraph.* Five pages are lists or grids and keep the measure anyway. On a 1440p monitor each sits in a 1280-pixel column, and three of them cap themselves further inside it. | Page | Template | What it holds | `<main>` at 2560 | Cap inside | | --- | --- | --- | --- | --- | | `/applications/report/` | `applications/report.html` | four `lg:grid-cols-4` grids of figures, a two-column grid, and a table in `.scroll-x` in the weekly view | 1280 | — | | `/applications/tags/` | `applications/tag_list.html` | a list of rows | 1280 | `max-w-2xl`, 672 | | `/jobs/industries/` | `jobs/industry_list.html` | a list of rows: code, name, counts, actions | 1280 | `max-w-2xl`, 672 | | `/documents/applications/<pk>/documents/` | `documents/application_documents.html` | three lists of rows | 1280 | `max-w-3xl`, 768 | | `/import/`, the mapping step | `core/import_csv_map.html` | two tables, one in `.scroll-x` | 1280 (read, not measured: the suite cannot reach it) | `max-w-4xl`, 1024 | The report is the dashboard's shape — the same four-column grids of figures — and the dashboard takes the screen. The import mapping is the #188 symptom exactly: a spreadsheet with a dozen columns previews in a box that scrolls sideways inside a 1024-pixel column inside a 1280-pixel column, on a screen twice that wide. Tags and industries are the two lists in Postulo that stayed at 672 pixels while every other list took the width, and *Industries* is the one #141 has been adding columns to. ## Where the line is, for the pages this does not name Kept at 1280 on purpose, per #188, and not filed as wrong here: every form; the application, company, posting, CV and letter pages; *Your career* (pinned as measured in `tests/test_width.py`); the career preview; and search results, which are a reading list. If the line should move — detail pages too, or everything — that is a change to the rule in `base.html` rather than a fix to these five, and worth its own issue. ## Proposal - Empty `main_width` in the five templates and drop their inner `max-w-*` wrappers, keeping a measure only around any paragraph of prose inside (the import page's explanations, say), the way the settings frames did in #198. - Add the five to `WIDE` in `tests/test_width.py`, and the import mapping through a client that has a spreadsheet stashed. - So the next one is caught rather than surveyed: a check over the rendered markup of every page the coverage test knows (`VISITED_URL_NAMES`) that a page holding a `<table>` or a `grid-cols` grid inside `<main>` has emptied `main_width`. The lists of plain rows would still need naming by hand; the tables and grids would not.

tiagoagueda added this to the 0.4.0 milestone

2026-09-18 10:12:46 +00:00

tiagoagueda added the

bug

interface

labels

2026-09-18 10:12:46 +00:00

tiagoagueda referenced this issue from a commit

2026-09-19 00:28:36 +00:00

Let the five lists and grids that kept the measure take the screen

tiagoagueda closed this issue

2026-09-19 00:28:36 +00:00