Tables tab: columns collapse by the list's own width, stacked rows (#2555)

[jh-RLI]

Closes #2555. Slice 3 of spec #2551.

The tables tab now fits its width from a wide screen to a phone without sideways scrolling. Columns collapse by the list's own width, using container queries on .dash. As the list narrows, Topics drops first (and Created, once it exists), then Review and Datasets. On the narrowest lists each row stacks into two lines: title and ⋯, then Status, Publishable and Modified. Where the filter bar does not fit on one line, everything but Search folds behind "Filters (n)". Stacked rows have no column headers, so a "Sort by" select takes their place.

What changed

• login/listing.py (generic, knows nothing about Tables):
  • Sort gains ascending/descending words.
  • ListPage.sort_options lists every sort in both directions, with the current one selected.
  • ListPage.folded_count counts the active filters behind the toggle (every one but free text).
• login/tables_tab.py: the four sorts declare their words: "Table: A to Z", "Status: drafts first", "Review: not reviewed first", "Datasets: most first", and so on. Ascending stays "least done first".
• list_sort_select.html (new, generic): the select, inside the swapped region, so it always shows the sort on screen. tables_tab.js rewrites its request the way it rewrites a filter's: every filter kept, page dropped.
• user_tables.html:
  • The "Filters (n)" toggle and one fold panel that holds every control but Search.
  • On a wide list the panel is display: contents, so the controls sit in the row as before.
  • The toggle only flips aria-expanded, and the CSS reads it. A fold left open in a narrow window therefore hides nothing in a wide one.
• tables_tab.css: the container queries, with the measurements beside them. Organization chips are capped at 11rem with an ellipsis; the full name is in title, and every holder is already in the link's aria-label. That bounds the Access column whatever an Organization is called (names may be up to 150 characters).
• benchmarks/tables_tab/ (new): seed.py ports the WF-06 prototype's generator (accounts p90 = 130, max = 2,068 mixed, maxreal = 2,068 as measured). run.py measures the row cost; widths.mjs measures the column widths in headless Chrome.

Measurement 1: thresholds, on the real row partial, sidebar shown

Taken in headless Chrome 152. Each number is the narrowest list a set of columns fits, on the worst of the first six pages of each account. The page uses the system font stack, which falls back to DejaVu Sans on Linux. That is one of the widest fonts, so the numbers are conservative; I re-measured this slice's row with Segoe UI injected as a web font.

The thresholds are set for the row as it will be once #2560 and #2561 are in too. Both are built and open. Together they make the row 50 px wider: #2561 adds the ⋯ menu, and #2560 makes the Publishable header sortable. I measured that on a trial merge of all three branches (see "Merge note"). With thresholds set for this slice's row alone, a 1280 screen would scroll the table by 16 px as soon as both land.

columns	this slice, DejaVu	this slice, Segoe UI	with #2560 + #2561, DejaVu	threshold
every column	980	912	1,030	1,050
without Topics	863	803	913	930
also without Review, Datasets	651	617	701	720
filter bar on one line	958	902	958	960 (folds below)

What that gives with the sidebar:

screen	list	columns	filter bar
1920	1,392	every column	one line
1440	976	without Topics (Review kept)	one line
1280	896	also without Review and Datasets	folded
1024	640	stacked + Sort by	folded
800	416	stacked + Sort by	folded
390	342	stacked + Sort by	folded

No sideways scrolling at 1920, 1440, 1280, 1024, 800 and 390 px. I checked each width on all three accounts, first six pages each, in both fonts, on this branch and on the trial merge with #2560 + #2561. The table never scrolls. The page scrolls at 1024 only, by 90–126 px in DejaVu and 0–3 px in Segoe UI, and that is the site navbar (see "Found, not fixed").

Departures from the issue, for you to rule on

1. The thresholds are not the issue's 1,360 / 1,100 / 900. Those came from the prototype, whose cells were wider: 1,340 px for the whole row, against about 1,050 here. Keeping 900 would have stacked a 1280 laptop that has room for columns.
2. The filter bar folds at its own width (960), not together with the stacking (720). On a single line the bar would wrap at 1280 while the rows stay columns. Folding by what the bar itself needs keeps it one line at 1440, as Tables tab: Review, Access, Topic, Tags and Dataset filters with chips and Reset #2556 tuned it, and folds it at 1280, where Tables tab: Review, Access, Topic, Tags and Dataset filters with chips and Reset #2556 expected the fold.
3. User story 104 (seven columns, Review kept, at 1280–1440) holds at 1440 only. At 1280 the sidebar leaves the list 896 px. That is less than the 913 px the row needs with Store the Publish gate result: Publishable filter and sort #2560 + Tables tab: row action pipeline, with publish and unpublish from the row #2561, so Review and Datasets drop there.
4. The thresholds are not set for the complete row. ☐ (Tables tab: selection, bulk bar and bulk publish/unpublish #2564), Modified (Tables tab: a real Modified date (data and metadata), default sort and range filter #2557) and Created (Tables tab: an honest Created date ('before Nov 2025' for older tables) #2559) do not exist yet. Measured with stand-ins for them, the complete row needs 1,294 / 1,047 / 835. Setting those now would leave four data columns at 1440 until those slices land. So each of them re-runs benchmarks/tables_tab/widths.mjs and moves the numbers; the CSS comment says so. Once they are in, Review also drops at 1440. Keeping it there would mean trimming about 90 px from the row, for example cell padding, the header sort arrows and the Table column's 13rem minimum. That is a design call, so it is not in this PR.

Measurement 2: server cost per row

Measured with python -m benchmarks.tables_tab.run, in the model-factsheet benchmark's style (throwaway database). Values are medians of 7 over the first 6 pages. Every request is 7 queries at every account size.

oemetadata per Table	per row (marginal)	building the rows	rendering
6 KB	0.8–1.2 ms	0.6–1.0 ms	0.34–0.47 ms
60 KB	1.4–2.2 ms	1.3–2.1 ms	0.34–0.47 ms
500 KB	5.8–7.5 ms	4.9–8.1 ms	0.34–0.47 ms

The old cards cost 6–10 ms each. A row stays below 10 ms, so nothing was trimmed. The rendering cost is constant. What grows is the oemetadata the live Publish gate decodes in the page query: real documents range from a few KB to 500 KB. If that ever matters, the lever is to fetch only the license part of the document rather than all of it.

Checked in a real browser (headless Chrome, real htmx, sidebar shown)

On the p90 account at 390 px, starting on page 3:

• Opening "Filters" reveals the controls.
• Choosing "Not reviewed" drops page=3, and the toggle reads "Filters (1)".
• "Sort by: published first" keeps the filter and focus returns to the select. Back to the default, sort leaves the URL.
• The back button restores the earlier state.
• Widening to 1920 with the fold left open hides nothing.
• A header sort at 1920 shows in the select after narrowing to 800.

Merge note: #2560 (PR #2576) and #2561 (PR #2575)

I trial-merged both onto this branch and resolved them, as a throwaway branch that is not pushed. Whichever of the three lands later will see these conflicts:

• login/listing.py and login/tables_tab.py (Store the Publish gate result: Publishable filter and sort #2560): both sides add fields to Sort; keep both. Store the Publish gate result: Publishable filter and sort #2560's new Publishable sort needs its words: Sort("publishable", "Publishable", F("publishable"), "not publishable first", "publishable first", nulls_last=True). SortSelectTests.test_every_sort_in_both_directions_least_done_first then gains the two Publishable entries.
• user_tables.html (Store the Publish gate result: Publishable filter and sort #2560): take this branch's version without the placeholder f-publishable. Store the Publish gate result: Publishable filter and sort #2560's real Publishable control is a ChoiceFilter, so the controls loop renders it inside the fold panel by itself.
• tables_tab.js, tables_tab.css, tables_region.html (Tables tab: row action pipeline, with publish and unpublish from the row #2561): union both sides.
• Not a textual conflict, but it breaks start-up: between Store the Publish gate result: Publishable filter and sort #2560 and Tables tab: row action pipeline, with publish and unpublish from the row #2561 themselves. Tables tab: row action pipeline, with publish and unpublish from the row #2561's api/services/table_actions.py imports PUBLISH_GATE from login.tables_tab, and Store the Publish gate result: Publishable filter and sort #2560 moves it to dataedit.publish_gate. Change the import whichever lands second.

On the merged tree: vitest is green (69 in login), the ⋯ menu opens in a stacked row at 390 px without overflow, and the widths are the "with #2560 + #2561" column above.

Found, not fixed (both predate this branch)

• The navbar overflows at 1024 px, on every profile tab, not only this one: the user menu and "Sign Out" (.ms-auto) stick out 90–126 px. That belongs to the navbar rework (Feature 2025 rework oep homepage #2352).
• The back button logs SyntaxError: Identifier 'reverseApiBaseUrl' has already been declared. htmx restores the page from its history cache and re-runs the inline const in base/templates/base/reverseUrl.html. The restored state is correct. Develop shows the same error on the same steps.

Tests

• login/tests/test_tables_narrow.py (11 tests): the Sort by options, labels and selection, including an unknown sort; the select riding in the region; the order of controls behind the toggle; folded_count (stale values and Search do not count); data-folded on an htmx swap.
• tables_tab.test.js (5 tests added): the Sort by request rewrite, focus back on the select, the toggle, "Filters (n)" following the region, and an open fold surviving a swap.
• login: 248 tests green. vitest: 135 green. QueryCountTests and FilterQueryCountTests are unchanged: still 7 unfiltered, 12 with every option filter named.
• Full suite on an isolated test DB: 1,142 run, 105 skipped (no Fuseki), one failure: the known oekg.tests.test_iri_resolution.LightImportTest, which cannot find the isolated settings module from its subprocess.
• The thresholds have no automated test: happy-dom has no layout. They are measured, and the numbers sit beside the queries.

🤖 Generated with Claude Code