78816dfe8c
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>
99 lines
5.1 KiB
Markdown
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.
|