diff --git a/devlog/_plan/260829_gui_dashboard_slop/020_phantom_grid_track.md b/devlog/_plan/260829_gui_dashboard_slop/020_phantom_grid_track.md index 6ead7444cb..eadf129cac 100644 --- a/devlog/_plan/260829_gui_dashboard_slop/020_phantom_grid_track.md +++ b/devlog/_plan/260829_gui_dashboard_slop/020_phantom_grid_track.md @@ -21,28 +21,41 @@ container is wide enough to nominally fit it. With only two children the track collapses to 0 and the trailing gap measures 0, so nothing shifts today. It becomes a real phantom gap the moment a third card is added. -## Change - -Both grids hold a *known* number of cards, so express that instead of asking -`auto-fit` to guess: - -```css -grid-template-columns: repeat(auto-fit, minmax(min(100%, 21rem), 1fr)); -``` - -becomes an explicit two-up that collapses to one column by container width: - -```css -grid-template-columns: 1fr; /* narrow: stack */ -@container / min-width: two-up → 1fr 1fr /* wide: matched pair */ -``` - -Applies to `.dash-sidecar-grid` and `.dash-overview-tools`. The wrap width stays -`21rem` per card so the responsive behaviour is unchanged — verified by the same -sweep, which must keep reporting STACKED at 900/430 and PAIRED at 1024+. - -## Acceptance - -- No `0px` track in either grid's computed columns at any swept width. -- The PAIRED/STACKED pattern per width matches the baseline exactly (no - behavioural change, only the phantom track removed). +## Why this was withdrawn — measured + +The claim above ("the trailing gap measures 0, so nothing shifts today") was the +reason to withdraw, but it went unmeasured on the axis the request named first — +the horizontal one. It has now been measured, by auditing the rendered edges of +each grid's direct children rather than reading the computed track list. + +`.dash-sidecar-grid` and `.dash-overview-tools`, two-up regime: + +| vw | card widths | top spread | bottom spread | gutters | +|----|-------------|-----------|---------------|---------| +| 1600 | 556 / 556 | 0.0px | 0.0px | one 16px | +| 1440 | 555 / 555 | 0.0px | 0.0px | one 16px | +| 1280 | 475 / 475 | 0.0px | 0.0px | one 16px | +| 1100 | 385 / 385 | 0.0px | 0.0px | one 16px | +| 1024 | 347 / 347 | 0.0px | 0.0px | one 16px | + +Identical widths, shared top and bottom edges, and exactly one gutter — no +trailing gap after the second card at any width. The collapsed third track +consumes no space and displaces nothing, in either grid, on both axes. So there +is no horizontal misalignment to fix here, and the generated-but-collapsed track +is not a defect. + +## The rewrite that was considered and rejected + +Recorded so it is not mistaken for a pending plan: **none of this shipped, and +applying it is not recommended.** + +The option was to stop asking `auto-fit` to guess and state the known card count +— `grid-template-columns: 1fr` with a container query promoting to `1fr 1fr` — +for both grids. It was rejected on cost against benefit: it fixes nothing +measurable today (see the table above), and it trades `auto-fit`'s automatic +behaviour for a hard-coded count, so a third card would then need a stylesheet +change instead of just appearing. The phantom track only becomes real if a third +card is added, and at that point `auto-fit` is what handles it correctly. + +If a future change does add a third card to either grid, re-measure the trailing +gap first; the audit above is the procedure. diff --git a/devlog/_plan/260829_gui_dashboard_slop/030_dynamic_viewport_units.md b/devlog/_plan/260829_gui_dashboard_slop/030_dynamic_viewport_units.md index 700e4d7b58..30a6b5891c 100644 --- a/devlog/_plan/260829_gui_dashboard_slop/030_dynamic_viewport_units.md +++ b/devlog/_plan/260829_gui_dashboard_slop/030_dynamic_viewport_units.md @@ -1,13 +1,17 @@ # 030 — Dynamic viewport units in scroll surfaces (wp3) -> **Implemented by this pull request**, separately from the sidecar alignment fix -> that the rest of this unit records. It is a different change to a different -> file (`gui/src/styles.css`), kept in the same unit because one audit pass found -> both. +> **Shipped in #2906** (`4d646c494`), separately from the sidecar alignment fix in +> #2905 that the rest of this unit records. It is a different change to a +> different file (`gui/src/styles.css`), kept in the same unit because one audit +> pass found both. +> +> Rules below are named by selector, not line number: the fix this document +> describes inserted lines above the very rules it cites, so the original +> citations (`styles.css:2003`, `:755`, `:1222`) now land on unrelated CSS. ## Defect -`gui/src/styles.css:2003`: +`.logs-table-wrap` in `gui/src/styles.css` (line 2011 as shipped): ```css .logs-table-wrap { max-height: calc(100vh - 260px); } @@ -15,11 +19,11 @@ `vh` is the *large* viewport: it ignores mobile browser chrome, so the log table is capped for a viewport taller than the one the user can see, pushing the last -rows under the browser UI. The rest of the shell already moved to `100dvh` -(styles.css:244, 247, 411, 412, 2198), so this line is an outlier, not a -convention. +rows under the browser UI. The rest of the shell already moved to `100dvh` — +`.app` (244), the sidebar (247), `.main-inner--combos` (411-412) and the mobile +drawer (2213) — so this line is an outlier, not a convention. -`styles.css:755` and `1222` cap toast width with `calc(100vw - Npx)`. Per CSS +`.action-toast` (749) and `.notice` (1215) cap toast width with `calc(100vw - Npx)`. Per CSS Values and Units 4, `100vw` includes the classic scrollbar gutter, so a scrollbar-reserving platform can in principle render a cap wider than the visible area. @@ -37,7 +41,7 @@ file at equal specificity, so source order won and the toast resolved to 70ch classes so it beats the later `.notice` rule. Both halves of the cap are restated: dropping the viewport term let the toast reach the screen edge at 430px (measured `left = 0`, losing the 24px inset the right side keeps). -- `styles.css:2003` is the only static `vh` in a scroll surface; the `12vh` +- `.logs-table-wrap` was the only static `vh` in a scroll surface; the `12vh` padding on the toast wrapper is decorative offset, not a size cap, and stays. ### Not changed: the `vw` → containing-block rewrite