Adriano Dal Pastro
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>
5.1 KiB
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, padding1rem / 1.5rem / 2remai 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 a56rem. È 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.100vhsu 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.