Files
TieMeasureFlow/docs/architecture/LAYOUT.md
T
Adriano Dal Pastro 78816dfe8c fix(ui): una cornice sola, e smette di spostarsi sotto le dita
Punto 14. La segnalazione dell'operatore del 28/07 non era stata circoscritta sul
codice: «le dimensioni delle viste cambiano a seconda del menu». Sono quattro
meccanismi distinti, tutti leggibili senza avere il tablet in mano.

Ogni vista si dichiarava la propria larghezza: sette valori diversi su diciassette
template, e nessuno coincideva con quello della navbar, che sta a max-w-7xl su
tutte. Il contenuto era quindi disallineato dalla barra sopra di sé, e il
disallineamento cambiava a ogni pagina. Il percorso dell'operatore faceva
1280 → 1024 → tutto schermo → 1280 in quattro passaggi.

Il padding verticale mescolava py-8 e py-6 fra viste consecutive, così la prima
card cambiava altezza a ogni schermata.

La barra di scorrimento è classica da 8px e occupa spazio: una pagina lunga la
mostrava, una corta no, e la schermata di misura la toglie sempre. A ogni
navigazione tutto il contenuto centrato — navbar compresa — si spostava di 8px.

La schermata di misura era alta 100vh, che su Android e iOS è l'altezza con la
barra dell'indirizzo nascosta: su un tablet il piede, dove stanno «Fine ciclo
misura» e il tastierino, finiva sotto il bordo.

Ora: .tmf-page e .tmf-page-narrow in themes.css, con i valori esatti della navbar;
scrollbar-gutter: stable; 100dvh dove serve. Due larghezze in tutto il prodotto al
posto di sette, e il criterio è il tipo di pagina — liste, tabelle e tele stanno
larghe, i moduli stanno stretti.

Login e schermata di misura tengono la loro geometria, per i motivi scritti in
docs/architecture/LAYOUT.md e ripetuti in EXEMPT dentro il test: la prima non ha
navbar a cui allinearsi, la seconda non deve scorrere mentre si misura.

Il test è statico e guarda i sorgenti: la vista scritta domani copierà la cornice
dalla vicina, ed è lì che la deriva ricomincia.

Resta da chiedere all'operatore su quale schermo l'ha vista: in verticale su un
tablet quasi tutte quelle larghezze collassano e il difetto non si nota.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-07-28 21:41:16 +00:00

99 lines
5.1 KiB
Markdown

# Cornice delle pagine
Nasce dal punto 14 del documento del 28/07: *«le dimensioni delle viste cambiano a
seconda del menu; passando da una schermata all'altra la finestra non mantiene
proporzioni stabili»*. La segnalazione era di un operatore e non era ancora stata
circoscritta sul codice. Questo è l'esito della circoscrizione e la regola che ne
è uscita.
## Cosa succedeva
Tre meccanismi distinti, tutti verificabili sul codice senza avere il tablet in mano.
**1. Ogni vista si dichiarava la propria larghezza.** Sette valori diversi su
diciassette template, e nessuno coincideva con quello della navbar, che sta a
`max-w-7xl` su tutte le pagine. Il contenuto risultava quindi disallineato dalla
barra sopra di sé, e il disallineamento cambiava da pagina a pagina.
| vista | prima | dopo |
|---|---|---|
| `measure/select_recipe.html` | `max-w-7xl` `py-8` | `tmf-page` |
| `measure/task_list.html` | `max-w-5xl` `py-8` | `tmf-page` |
| `measure/task_complete.html` | `max-w-7xl` `py-6` | `tmf-page` |
| `maker/recipe_list.html` | `max-w-6xl` `py-8` | `tmf-page` |
| `maker/task_editor.html` | `max-w-5xl` `py-8` | `tmf-page` |
| `maker/task_drawing.html` | `max-w-5xl` `py-8` | `tmf-page` |
| `maker/recipe_preview.html` | `max-w-5xl` `py-8` | `tmf-page` |
| `admin/stations.html` | `max-w-7xl` `py-6` | `tmf-page` |
| `admin/users.html` | `max-w-7xl` `py-6` | `tmf-page` |
| `statistics/dashboard.html` | `max-w-7xl` `py-6` | `tmf-page` |
| `admin/settings.html` | `max-w-3xl` `py-6` | `tmf-page tmf-page-narrow` |
| `auth/profile.html` | `max-w-4xl` `py-8` | `tmf-page tmf-page-narrow` |
| `maker/recipe_editor.html` | `max-w-4xl` `py-8` | `tmf-page tmf-page-narrow` |
| `maker/version_history.html` | `max-w-4xl` `py-8` | `tmf-page tmf-page-narrow` |
| `errors/station_not_configured.html` | `max-w-2xl` `py-8` | `tmf-page tmf-page-narrow` |
Il percorso dell'operatore — quello da cui è arrivata la segnalazione — faceva
`1280px → 1024px → tutto schermo → 1280px` in quattro passaggi.
**2. Il padding verticale non era lo stesso.** `py-8` e `py-6` mescolati fra viste
consecutive: la prima card si trovava a un'altezza diversa a ogni cambio di
schermata.
**3. La barra di scorrimento appariva e spariva.** È una barra classica da 8px
(`themes.css`, `::-webkit-scrollbar`), quindi occupa spazio nel layout. Una pagina
lunga la mostrava, una corta no, e la schermata di misura la toglie sempre
(`body { overflow: hidden }`): a ogni navigazione tutto il contenuto centrato —
navbar compresa — si spostava di 8px in orizzontale.
## La regola
Due classi in `static/css/themes.css`, nessuna larghezza nei template.
- **`.tmf-page`** — la cornice: `max-width: 80rem`, padding `1rem / 1.5rem / 2rem`
ai tre breakpoint, `padding-block: 1.5rem`. Sono esattamente i valori della
navbar (`max-w-7xl px-4 sm:px-6 lg:px-8`), così il contenuto ci si allinea.
- **`.tmf-page-narrow`** — si aggiunge alla prima e stringe a `56rem`. È per i
moduli: un campo di testo largo 1280px non si compila meglio.
- **`html { scrollbar-gutter: stable }`** — lo spazio della barra è riservato
sempre, anche dove la pagina non scorre.
- **`body.h-screen { height: 100dvh }`** — la schermata di misura è alta quanto la
finestra vera. `100vh` su Android e iOS è l'altezza che la pagina avrebbe con la
barra dell'indirizzo nascosta: su un tablet il piede della schermata — dove
stanno «Fine ciclo misura» e il tastierino — finiva sotto il bordo, e ricompariva
quando la barra si ritraeva.
Due larghezze in tutto il prodotto al posto di sette, e il criterio è il tipo di
pagina: liste, tabelle e tele di disegno stanno larghe, i moduli stanno stretti.
## Le due eccezioni
Hanno geometria propria per un motivo, e sono elencate in
`tests/test_layout_shell.py` perché non sembrino dimenticate.
- **`auth/login.html`** — schermata piena senza navbar: non c'è niente a cui
allinearsi.
- **`measure/task_execute.html`** — la schermata di misura è un pannello a tutta
altezza che non deve scorrere mentre un operatore sta misurando
(`h-screen overflow-hidden`, footer nascosto). È l'unica vista in cui il cambio
di forma è voluto, ed è anche l'unica in cui l'operatore si ferma a lavorare:
entrarci e uscirne resta un salto, ma ora è l'unico.
## Cosa resta da verificare sul campo
La segnalazione non è mai stata riprodotta su un dispositivo: quanto sopra viene
dalla lettura del codice, non da una prova. Quello che è dimostrato è che il
layout *poteva* muoversi per quattro motivi distinti e che ora non può più per
nessuno dei quattro.
Se l'operatore vedesse ancora spostamenti, il sospetto successivo è la **tastiera
virtuale**: quando compare, il browser ridimensiona la finestra, e con `100dvh` la
schermata di misura si ridimensiona con lei invece di scorrere sotto. È il
comportamento giusto per il tastierino a schermo, ma va guardato con un calibro
USB collegato, dove la tastiera di sistema non dovrebbe comparire affatto.
Da chiedere all'operatore che ha aperto la segnalazione: **su quale schermo** l'ha
vista. Su un tablet in verticale la maggior parte delle larghezze qui sopra
collassa allo stesso valore e il difetto non si vede; su un monitor da scrivania
si vede tutto.