padding hero infrastruttura-cloud 130px 104 36 26 chi-siamo 122px 96 28 26 hosting 114px 88 36 26 filemaker 84px 58 36 26 analizziamo 62px 36 36 26 contatti 59px - 0 26 applicativi 54px 28 0 26 Tre residui del layout desktop, che si sommano: 1. `.hero-inner` e' la griglia a due colonne del desktop. Collassata a una, mantiene una traccia vuota che continua a occupare spazio. 2. Il `row-gap` della griglia resta quello desktop: 20 px, e su analizziamo addirittura 90 px. 3. L'ultimo paragrafo conserva il suo `margin-bottom` (28-36 px), che sul desktop serve a staccarlo da cio' che segue nella colonna. Qui sotto non c'e' piu' niente: e' vuoto puro. A questi si somma il `padding-bottom` dell'hero, che invece serve e resta — ridotto da 26 a 20 px. ============================================================================ */ @media (max-width: 820px) { /* -------------------------------------------------------------------------- A. Le tracce vuote della griglia spariscono `:empty` colpisce solo gli elementi realmente privi di contenuto, quindi le celle rimaste orfane del layout a due colonne. -------------------------------------------------------------------------- */ body[class*="page-"] .hero-inner > *:empty { display: none; } /* -------------------------------------------------------------------------- B. Gap della griglia riportato a una misura da mobile Era 20 px su quasi tutte e 90 px su analizziamo. -------------------------------------------------------------------------- */ body[class*="page-"] .hero-inner { row-gap: 0; align-content: start; } /* -------------------------------------------------------------------------- C. L'ultimo elemento non ha piu' niente sotto di se': via il margine -------------------------------------------------------------------------- */ body[class*="page-"] .hero .hero-inner > *:last-child, body[class*="page-"] .contact-hero .hero-inner > *:last-child, body[class*="page-"] .hero p:last-of-type, body[class*="page-"] .contact-hero p:last-of-type { margin-bottom: 0; } /* -------------------------------------------------------------------------- D. Padding di chiusura dell'hero, ridotto ma non azzerato: serve a non far toccare il testo al bordo della sezione successiva -------------------------------------------------------------------------- */ body[class*="page-"]:not(.page-home) .hero, body[class*="page-"] .contact-hero { padding-bottom: 20px; } } @media (max-width: 520px) { body[class*="page-"]:not(.page-home) .hero, body[class*="page-"] .contact-hero { padding-bottom: 16px; } } /* ============================================================================ RISULTATO ATTESO ---------------------------------------------------------------------------- Il vuoto sotto il testo dovrebbe scendere dai 54-130 px attuali a circa 16-20 px su tutte le pagine, cioe' al solo padding di chiusura. Se dopo questa patch una pagina mostra ancora spazio di troppo, il colpevole e' probabilmente un elemento decorativo (una riga, un separatore) che non e' `:empty` perche' contiene qualcosa. Si trova cosi', in console: const h = document.querySelector('.hero'); [...h.querySelectorAll('*')] .filter(e => e.getBoundingClientRect().height > 0) .slice(-3) .map(e => e.tagName + '.' + e.className + ' h=' + Math.round(e.getBoundingClientRect().height)) Mostra gli ultimi tre elementi con altezza reale: se fra loro c'e' qualcosa che non ti aspetti, e' quello. ---------------------------------------------------------------------------- Il `padding-bottom` di 20 px e' l'unica manopola volontaria rimasta: si puo' portare a 0 se vuoi il testo attaccato alla sezione successiva, ma di solito un minimo di stacco aiuta a separare i blocchi. ============================================================================ */ /* ############################################################################ # # # PATCH 12 — inquadratura delle immagini hero su mobile # # # # Va incollato IN FONDO a style.css, DOPO la PATCH 11. # # # ############################################################################ */ /* ============================================================================ IL PROBLEMA E' DENTRO I FILE, NON NEL CSS ---------------------------------------------------------------------------- Le immagini hero sono state preparate per il layout desktop: il testo sta a sinistra, quindi la meta' sinistra dell'immagine e' sfumata verso il bianco per farlo risaltare. La sfumatura e' incorporata nel PNG. Luminanza misurata da sinistra a destra (255 = bianco): PAGINA SINISTRA -> DESTRA ZONA LAVATA chi-siamo 254 249 216 141 75 50 29 12 25% analizziamo 249 249 243 227 215 202 224 199 38% applicativi 251 249 245 239 220 227 225 192 50% filemaker 245 248 248 239 232 229 223 193 50% contatti 241 241 242 241 238 224 215 201 63% infrastruttura 215 192 177 151 92 79 86 84 0% hosting 222 224 229 233 238 238 237 236 0% (uniforme) Su mobile la banda mostra tutta la larghezza, quindi il primo quarto (o meta') dell'immagine appare come una zona slavata senza contenuto. PERCHE' `object-position` DA SOLO NON BASTA La banda e' 375x200 (proporzione 1.875), le immagini sono circa 1536x1024 (1.5). Con `object-fit: cover` il browser scala sulla LARGHEZZA e ritaglia in ALTEZZA: la larghezza viene mostrata per intero, zona lavata compresa, e `object-position` orizzontale non ha alcun effetto perche' non c'e' niente da spostare. LA SOLUZIONE Ingrandire l'immagine dentro la banda ancorandola al bordo destro: si vede solo la porzione che contiene davvero il soggetto. `scale(1.7)` con origine a destra mostra il 59% destro dell'immagine, cioe' dal 41% in poi. Nessuna perdita di qualita': anche ingrandita, la larghezza richiesta resta circa 640 px contro i 1536 dell'originale. ============================================================================ */ @media (max-width: 820px) { /* la banda ritaglia quello che esce */ body[class*="page-"] .hero .hero-bg, body[class*="page-"] .contact-hero .contact-hero-bg { overflow: hidden; } /* -------------------------------------------------------------------------- Inquadratura ancorata a destra. Valore unico per le pagine con sfumatura marcata. -------------------------------------------------------------------------- */ body[class*="page-"] .hero .hero-bg img, body[class*="page-"] .contact-hero .contact-hero-bg img { transform: scale(1.7); transform-origin: right center; } /* -------------------------------------------------------------------------- ECCEZIONI -------------------------------------------------------------------------- */ /* hosting: luminanza 222-238 costante su tutta la larghezza, nessuna sfumatura da evitare. Ingrandirla toglierebbe soltanto inquadratura. */ body[class*="page-"] .hero-hosting .hero-bg img { transform: none; } /* infrastruttura: la sfumatura e' dolce (215 -> 84) e il soggetto occupa gia' quasi tutta la larghezza. Basta un ingrandimento leggero. */ body[class*="page-"] .hero-infrastruttura .hero-bg img { transform: scale(1.25); } /* contatti: zona lavata fino al 63%, la piu' estesa. Serve piu' zoom. */ body[class*="page-"] .contact-hero .contact-hero-bg img { transform: scale(2.1); } } /* ============================================================================ COME REGOLARE, PAGINA PER PAGINA ---------------------------------------------------------------------------- Il valore di `scale` decide quanta parte sinistra viene esclusa: scale(1.3) -> mostra il 77% destro (esclude il 23% sinistro) scale(1.5) -> mostra il 67% destro scale(1.7) -> mostra il 59% destro <- valore generale scale(2.0) -> mostra il 50% destro scale(2.5) -> mostra il 40% destro Regola pratica: `scale = 1 / (1 - percentuale_lavata)`. Per chi-siamo, lavata al 25%: 1 / 0.75 = 1.33 sarebbe il minimo; 1.7 da' un margine di sicurezza e centra meglio il soggetto. Alzando troppo lo zoom si perde contesto e l'immagine diventa un dettaglio irriconoscibile: meglio restare sotto 2.5. ---------------------------------------------------------------------------- LA SOLUZIONE MIGLIORE, QUANDO CI SARA' TEMPO Questa patch e' un rimedio: sta ritagliando immagini pensate per un altro formato. La soluzione pulita e' esportare una versione mobile di ogni hero, senza sfumatura e gia' inquadrata per un formato orizzontale basso, da servire con e media query. Vantaggi: nessun ingrandimento, inquadratura decisa da chi ha fatto la grafica invece che da una formula, e file molto piu' leggeri — le attuali sono da 1536-1717 px di larghezza per essere mostrate a 375. ============================================================================ */ /* ############################################################################ # # # PATCH 13 — correzione home + vuoto residuo nell'hero # # # # Va incollato IN FONDO a style.css, DOPO la PATCH 12. # # # ############################################################################ */ /* ============================================================================ 1. CORREZIONE: la home aveva preso lo zoom della PATCH 12 ---------------------------------------------------------------------------- Nelle PATCH 9 e 10 la home era stata esclusa con `:not(.page-home)`, perche' e' l'unica che mantiene il layout sovrapposto (testo bianco su immagine scura). Nella PATCH 12 quell'esclusione e' stata dimenticata, quindi la home ha ricevuto `transform: scale(1.7)` su un'immagine che li' fa da sfondo a tutta la sezione: risultato, inquadratura ingrandita senza motivo. Qui viene annullato. La home torna esattamente com'era dopo la PATCH 3. ============================================================================ */ @media (max-width: 820px) { body.page-home .hero .hero-bg img { transform: none; } } /* ============================================================================ 2. VUOTO RESIDUO SOTTO IL TESTO — la griglia che non serve piu' ---------------------------------------------------------------------------- Dopo la PATCH 11 il vuoto era sceso da 122 a 64 px, ma non ai 20 previsti. MISURA su chi-siamo: il testo finisce a 466 px .hero-inner finisce a 514 px <- 48 px di spazio riservato .hero finisce a 530 px <- 16 px di padding, corretti CAUSA `.hero-inner` e' la griglia a due colonne del desktop. Su mobile ha ancora DUE celle: la prima con il testo, la seconda — quella dell'immagine — alta zero ma pur sempre una traccia della griglia. La regola `:empty` della PATCH 11 non la intercetta, perche' quel `div` non e' realmente vuoto: contiene un elemento annidato che a sua volta non produce altezza. `:empty` guarda i figli, non l'altezza risultante. SOLUZIONE Su mobile `.hero-inner` non ha piu' bisogno di essere una griglia: deve solo impilare i suoi contenuti. Con `display: block` le tracce spariscono, e con loro gap, righe fantasma e distribuzione dello spazio. E' anche piu' solido di qualsiasi regola che cerchi di neutralizzare la griglia pezzo per pezzo. ============================================================================ */ @media (max-width: 820px) { body[class*="page-"] .hero-inner { display: block; } /* i figli diretti tornano a comportarsi da blocchi impilati */ body[class*="page-"] .hero-inner > * { width: auto; max-width: 100%; } /* l'ultimo elemento non ha nulla sotto di se' */ body[class*="page-"] .hero-inner > *:last-child, body[class*="page-"] .hero-inner > *:last-child > *:last-child { margin-bottom: 0; } } /* ============================================================================ RISULTATO ATTESO ---------------------------------------------------------------------------- Il vuoto sotto il testo scende a 16-20 px su tutte le pagine: il solo padding di chiusura dell'hero, che serve a separarlo dalla sezione successiva. Per verificarlo, in console a 375 px: const h = document.querySelector('.hero, .contact-hero'); const t = [...h.querySelectorAll('h1,p,a,ul')] .filter(e => e.getBoundingClientRect().height > 0).pop(); Math.round(h.getBoundingClientRect().bottom - t.getBoundingClientRect().bottom) ---------------------------------------------------------------------------- NOTA `display: block` su un contenitore nato come griglia e' spesso la mossa piu' pulita quando su mobile serve solo impilare: evita di dover azzerare a mano colonne, righe, gap e allineamenti, e non lascia tracce fantasma. ============================================================================ */ /* ############################################################################ # # # PATCH 14 — padding interno dell'hero e interruzioni di riga # # # # Va incollato IN FONDO a style.css, DOPO la PATCH 13. # # # ############################################################################ */ /* ============================================================================ 1. IL PADDING CHE RESISTEVA ---------------------------------------------------------------------------- Ogni pagina ha un padding proprio su `.hero-inner`, con selettori piu' specifici di quelli usati finora: .hero-about .hero-inner padding-top: 48px .hero-infrastruttura .hero-inner padding-top: 4px .page-infrastruttura .hero-inner padding-top: 4px La PATCH 7 azzerava `.hero-inner` (specificita' 0,1,0) e perdeva contro `.hero-about .hero-inner` (0,2,0). Il prefisso `body[class*="page-"]` porta a 0,3,1 e vince su tutte. Il valore viene uniformato a 24 px sopra — uno stacco dall'immagine uguale per tutte le pagine — e 0 sotto, perche' li' chiude gia' il padding dell'hero. ============================================================================ */ @media (max-width: 820px) { body[class*="page-"] .hero .hero-inner, body[class*="page-"] .contact-hero .hero-inner, body[class*="page-"] .contact-hero .contact-hero-inner { padding-top: 24px; padding-bottom: 0; } /* l'ultimo blocco di testo non ha nulla sotto di se' */ body[class*="page-"] .hero .hero-inner > *:last-child, body[class*="page-"] .hero .hero-inner > *:last-child > *:last-child, body[class*="page-"] .contact-hero .contact-hero-inner > *:last-child { margin-bottom: 0; padding-bottom: 0; } } /* ============================================================================ 2. LE INTERRUZIONI DI RIGA DEL DESKTOP ---------------------------------------------------------------------------- Nei titoli e nei paragrafi dell'hero ci sono `` inseriti per spezzare il testo in punti precisi sul desktop, dove la colonna e' larga: infrastruttura-cloud alto 38 px dentro l'h1 hosting alto 23 px dentro il paragrafo Su 375 px il testo va gia' a capo da solo, e quel `` non spezza niente: aggiunge una riga vuota. Vengono disattivati SOLO dentro l'hero: altrove nel sito potrebbero servire davvero, e questa patch non li tocca. ============================================================================ */ @media (max-width: 820px) { body[class*="page-"] .hero h1 br, body[class*="page-"] .hero .hero-sub br, body[class*="page-"] .contact-hero h1 br, body[class*="page-"] .contact-hero p br { display: none; } } /* ============================================================================ VERIFICA ---------------------------------------------------------------------------- In console, a 375 px, su ciascuna pagina: const h = document.querySelector('.hero, .contact-hero'); const t = [...h.querySelectorAll('h1,p')] .filter(e => e.getBoundingClientRect().height > 0).pop(); ({ sopra: Math.round( h.querySelector('h1').getBoundingClientRect().top - h.querySelector('.hero-bg, .contact-hero-bg').getBoundingClientRect().bottom), sotto: Math.round(h.getBoundingClientRect().bottom - t.getBoundingClientRect().bottom) }) Atteso: circa 24 px sopra il titolo (stacco dall'immagine) e 16 px sotto l'ultimo testo (chiusura dell'hero). ---------------------------------------------------------------------------- NOTA Il padding di `.hero-inner` era gia' stato azzerato nella PATCH 7, ma con un selettore troppo debole. E' il terzo caso in questa serie in cui una regola sembrava non funzionare ed era solo meno specifica di quella che stava provando a sovrascrivere: conviene verificarlo per primo, prima di riscrivere la regola. ============================================================================ */ /* ############################################################################ # # # PATCH 15 — separatori verticali e rientri del layout a colonne # # # # Va incollato IN FONDO a style.css, DOPO la PATCH 14. # # # ############################################################################ */ /* ============================================================================ COSA SONO QUESTE LINEE ---------------------------------------------------------------------------- Sulla pagina Infrastruttura si vedono due linee verticali fuori posto: una staccata a sinistra dei blocchi, una che taglia il testo a meta'. Cercandole su tutte le pagine, sono la stessa cosa ripetuta 20 volte. Sono due meccanismi diversi che il desktop usa per separare le colonne: A) PSEUDO-ELEMENTI: una linea in `position: absolute` disegnata fra le due colonne della griglia. Con la griglia collassata resta dov'era e finisce in mezzo al contenuto. .infra-sysadmin-grid::before 1 x 827 px a 159 px da sinistra .hosting-fit-grid::before 1 x 645 px .applicativi-build-item::before 1 x 310 px B) BORDER-LEFT sulle card: sul desktop, affiancate, il bordo sinistro fa da divisorio fra una colonna e l'altra. Impilate su mobile, diventa una riga verticale a sinistra che non separa piu' niente. ---------------------------------------------------------------------------- COME SONO STATI DISTINTI I CASI Non tutti i `border-left` sono errori: alcuni sono accenti decorativi voluti. Il criterio e' il COLORE. AZZURRO Vincasoft — rgb(31,160,208), rgba(22,122,153,...) e derivati Accento di marca, deliberato. RESTA. .about-continuity-node .about-panel-card .analisi-intro-card .analisi-form-note .analisi-step-card .analisi-target-item .analisi-form .hosting-position-point GRIGIO NEUTRO — rgb(226,232,240), rgba(203,213,225,...), rgba(7,21,42,...) Divisorio strutturale, senza significato una volta impilato. VIA. .home-service-item .infra-environment-item .contact-direct-item .contact-location .contact-request-item .filemaker-position-item .applicativi-technology-item Eccezione: `.hosting-included-item` ha un bordo azzurro tenue ma sul desktop sta in una griglia a 5 colonne, quindi li' e' un divisorio a tutti gli effetti: va tolto anche quello. ---------------------------------------------------------------------------- IL PROBLEMA PIU' GRANDE: I RIENTRI Il `border-left` viaggia sempre con un `padding-left` che gli fa spazio, e quei valori sono pensati per una colonna larga: .contact-request-item 68 px = 18% dello schermo .filemaker-difference-text 48 .analisi-form 46 .contact-location 44 .contact-direct-item 42 .filemaker-position-item 42 .analisi-intro-card 40 .analisi-step-card 36 .analisi-target-item 36 .applicativi-technology-item 36 .infra-environment-item 34 Su 375 px di larghezza sono decine di pixel sottratti al testo su ogni riga. Vengono ridotti a 16 px dove l'accento resta, azzerati dove il bordo se ne va. ============================================================================ */ @media (max-width: 820px) { /* -------------------------------------------------------------------------- A. Le linee disegnate fra le colonne -------------------------------------------------------------------------- */ body[class*="page-"] .infra-sysadmin-grid::before, body[class*="page-"] .hosting-fit-grid::before, body[class*="page-"] .applicativi-build-item::before, body[class*="page-"] .infra-split-grid::before { display: none; } /* -------------------------------------------------------------------------- B. I divisori grigi: via bordo e rientro -------------------------------------------------------------------------- */ body[class*="page-"] .home-service-item, body[class*="page-"] .infra-environment-item, body[class*="page-"] .contact-direct-item, body[class*="page-"] .contact-location, body[class*="page-"] .contact-request-item, body[class*="page-"] .filemaker-position-item, body[class*="page-"] .applicativi-technology-item, body[class*="page-"] .hosting-included-item { border-left: 0; padding-left: 0; } /* -------------------------------------------------------------------------- C. Gli accenti azzurri restano, ma con un rientro da mobile 16 px bastano a staccare il testo dalla barretta senza mangiare riga. -------------------------------------------------------------------------- */ body[class*="page-"] .about-continuity-node, body[class*="page-"] .about-panel-card, body[class*="page-"] .analisi-intro-card, body[class*="page-"] .analisi-form-note, body[class*="page-"] .analisi-step-card, body[class*="page-"] .analisi-target-item, body[class*="page-"] .analisi-form, body[class*="page-"] .hosting-position-point, body[class*="page-"] .filemaker-difference-text { padding-left: 16px; } } /* ============================================================================ VERIFICA ---------------------------------------------------------------------------- In console, a 375 px, su ogni pagina — deve restituire un array vuoto: [...document.querySelectorAll('*')].filter(el => { const cs = getComputedStyle(el); return parseFloat(cs.borderLeftWidth) > 0 && el.getBoundingClientRect().height > 60 && parseFloat(cs.paddingLeft) > 20; }).map(el => el.className) E per le linee verticali: [...document.querySelectorAll('*')].filter(el => { const b = getComputedStyle(el, '::before'); return b.content !== 'none' && parseFloat(b.width) > 0 && parseFloat(b.width) <= 6 && parseFloat(b.height) > 60; }).map(el => el.className) ---------------------------------------------------------------------------- NOTA Questi separatori non erano rilevabili dai controlli fatti finora: non producono sforamento, non generano sovrapposizioni, non toccano il contrasto. Sono semplicemente elementi grafici che hanno perso il loro significato quando il layout e' passato da due colonne a una. Vale la pena cercarli anche in futuro, dopo ogni collasso di griglia: un divisorio ha senso solo finche' c'e' qualcosa da dividere. ============================================================================ */ /* ============================================================ PATCH 16 — rientri residui senza bordo ------------------------------------------------------------ Tre contenitori hanno un padding-left dimensionato per la colonna desktop ma nessun border-left, quindi erano sfuggiti al controllo della PATCH 15 che cercava la coppia bordo+rientro. .filemaker-problem-content arrivava a 78px: il 21% di 375. ============================================================ */ @media (max-width: 820px) { body[class*="page-"] .filemaker-problem-content, body[class*="page-"] .applicativi-build-item, body[class*="page-"] .infra-sysadmin-col { padding-left: 0; } } /* ============================================================ PATCH 17 — ripristino delle card ------------------------------------------------------------ Nella PATCH 15 il border-left di questi elementi era stato classificato come separatore di colonna. Sbagliato: sono card con sfondo, ombra e raggio, e quel bordo era il quarto lato della cornice. Il padding-left non faceva spazio al bordo, era il padding interno della card. Risultato: cornice aperta a sinistra e testo appoggiato al bordo. Gli altri elementi della PATCH 15 sono trasparenti e senza contorno: per quelli padding-left: 0 resta corretto. ============================================================ */ @media (max-width: 820px) { body[class*="page-"] .home-service-item { border-left: 1px solid rgb(226, 232, 240); padding-left: 28px; } body[class*="page-"] .hosting-included-item { border-left: 1px solid rgba(31, 160, 208, .18); padding-left: 22px; } /* niente bordo, ma ha sfondo proprio: serve respiro interno. Il valore originale era 78px, eccessivo su 375. */ body[class*="page-"] .filemaker-problem-content { padding-left: 24px; } } /* ############################################################################ # # # PATCH 18 — pagina hosting # # # # Va incollato IN FONDO a style.css, DOPO la PATCH 17. # # # ############################################################################ */ /* ============================================================================ PERCHE' HOSTING E' RIMASTA INDIETRO ---------------------------------------------------------------------------- Su questa pagina TUTTE le regole di layout sono scritte con il prefisso `.page-hosting`, quindi hanno specificita' 0,2,0. Le regole mobile scritte finora usano la sola classe del componente (0,1,0) e perdono ogni confronto. Risultato: quattro griglie non hanno mai collassato, pur essendo elencate sia nel blocco mobile sia nella PATCH 1. GRIGLIA STATO A 375 px .hosting-real-items 3 colonne da 8 px <- illeggibile .hosting-position-points 3 colonne da 91 px .hosting-fit-grid 2 colonne da 123 px .hosting-real-grid 2 colonne (168 + 186) In piu' due `min-height: 420px` sovrapposti — uno sull'immagine, uno sul testo — che con la griglia non collassata portano la sezione `.hosting-real` a 3.158 px: un terzo dell'intera pagina. E una linea verticale `.hosting-fit-grid::before` (`left: 50%; width: 1px`), il divisorio fra le due colonne, rimasta in mezzo al contenuto. Tutte le regole qui sotto usano `body[class*="page-"]` (0,3,1) per stare sopra a `.page-hosting` senza ricorrere a !important. ============================================================================ */ @media (max-width: 820px) { /* -------------------------------------------------------------------------- A. Le quattro griglie collassano davvero -------------------------------------------------------------------------- */ body[class*="page-"] .hosting-position-points, body[class*="page-"] .hosting-real-grid, body[class*="page-"] .hosting-real-items, body[class*="page-"] .hosting-fit-grid, body[class*="page-"] .hosting-growth-inner, body[class*="page-"] .hosting-managed-grid { grid-template-columns: minmax(0, 1fr); gap: 20px; } /* -------------------------------------------------------------------------- B. Il divisorio fra le due colonne -------------------------------------------------------------------------- */ body[class*="page-"] .hosting-fit-grid::before { display: none; } /* -------------------------------------------------------------------------- C. Le due altezze minime da 420 px Sul desktop servono a tenere immagine e testo della stessa altezza, affiancati. Impilati non hanno piu' senso: l'immagine diventa una fascia, il testo si adatta al proprio contenuto. -------------------------------------------------------------------------- */ body[class*="page-"] .hosting-real-media, body[class*="page-"] .hosting-real-media img { min-height: 0; height: 200px; object-fit: cover; } body[class*="page-"] .hosting-real-content { min-height: 0; height: auto; padding: 24px; /* era 34px 64px 32px */ } /* -------------------------------------------------------------------------- D. Gli altri padding tarati sulla colonna desktop -------------------------------------------------------------------------- */ body[class*="page-"] .hosting-box, body[class*="page-"] .hosting-managed-card, body[class*="page-"] .hosting-offer { padding-left: 20px; padding-right: 20px; } } /* ============================================================================ NOTA — QUESTO CASO VALE PER TUTTO IL CSS ---------------------------------------------------------------------------- E' la quinta volta in questa serie che una regola mobile "non funziona" e la causa e' la specificita'. Il sito usa due convenzioni diverse: .hosting-real-grid componente puro 0,1,0 .page-hosting .hosting-real-grid componente per-pagina 0,2,0 Le due convivono nello stesso foglio, e la seconda vince sempre. AL CONSOLIDAMENTO conviene sceglierne una sola. La piu' pulita e' la prima: il prefisso di pagina serve solo quando lo stesso componente deve apparire diverso su pagine diverse, che qui non succede quasi mai. Uniformando, le media query tornano a funzionare con la sola classe del componente e sparisce tutta questa categoria di problemi. Nel frattempo, la regola pratica: se una regola mobile sembra ignorata, cercare chi la sta battendo PRIMA di riscriverla. ============================================================================ */ /* ############################################################################ # # # PATCH 19 — pagina FileMaker # # # # Va incollato IN FONDO a style.css, DOPO la PATCH 18. # # # ############################################################################ */ /* ============================================================================ PRIMA: UN ERRORE DI CALCOLO NELLE PATCH PRECEDENTI ---------------------------------------------------------------------------- Ho usato piu' volte `body[class*="page-"] .componente` dandogli specificita' 0,3,1. E' sbagliato: vale 0,2,1. body tipo 0,0,1 [class*="..."] attributo 0,1,0 .componente classe 0,1,0 ------------------------------------ totale 0,2,1 Contro `.page-filemaker .hero-filemaker .hero-inner`, che vale 0,3,0, quel selettore PERDE. Su applicativi funzionava solo perche' li' la regola originale e' piu' corta (`.hero-applicativi .hero-inner`, 0,2,0). Serve una classe in piu' nel percorso: body[class*="page-"] .hero .hero-inner -> 0,3,1 vince Le regole di questa patch usano quella forma. ============================================================================ */ @media (max-width: 820px) { /* -------------------------------------------------------------------------- A. L'hero-inner di FileMaker era rimasto a due colonne (115 px + 127 px), da cui un hero di 994 px -------------------------------------------------------------------------- */ body[class*="page-"] .hero .hero-inner, body[class*="page-"] .hero.hero-filemaker .hero-inner { display: block; } /* -------------------------------------------------------------------------- B. Le griglie della sezione "caso" .filemaker-case-steps 3 colonne da 90 px .filemaker-case-benefits 4 colonne da 63 px <- illeggibili -------------------------------------------------------------------------- */ body[class*="page-"] .filemaker-case .filemaker-case-steps, body[class*="page-"] .filemaker-case .filemaker-case-benefits, body[class*="page-"] .filemaker-case-steps, body[class*="page-"] .filemaker-case-benefits { grid-template-columns: minmax(0, 1fr); gap: 16px; } /* -------------------------------------------------------------------------- C. Le altezze minime del desktop Servono a tenere allineate le colonne affiancate. Impilate, diventano solo spazio vuoto: la sezione .filemaker-problem misura 1.659 px. -------------------------------------------------------------------------- */ body[class*="page-"] .filemaker-problem .filemaker-problem-grid, body[class*="page-"] .filemaker-case .filemaker-case-grid, body[class*="page-"] .filemaker-difference { min-height: 0; height: auto; } body[class*="page-"] .filemaker-problem .filemaker-problem-media img, body[class*="page-"] .filemaker-problem-media img { min-height: 0; height: 200px; object-fit: cover; } /* -------------------------------------------------------------------------- D. Padding tarati sulla colonna desktop .filemaker-problem-content aveva 78 px a destra -------------------------------------------------------------------------- */ body[class*="page-"] .filemaker-problem .filemaker-problem-content, body[class*="page-"] .filemaker-problem-content { padding-left: 20px; padding-right: 20px; } body[class*="page-"] .filemaker-position .filemaker-position-item, body[class*="page-"] .filemaker-position-item { padding-right: 0; } /* -------------------------------------------------------------------------- E. Card rimaste senza respiro interno Stesso caso della PATCH 17: hanno sfondo o bordo propri, quindi il padding orizzontale e' contenuto, non rientro. -------------------------------------------------------------------------- */ body[class*="page-"] .filemaker-problem-point, body[class*="page-"] .filemaker-case-benefits { padding-left: 18px; padding-right: 18px; } body[class*="page-"] .filemaker-difference .filemaker-difference-text, body[class*="page-"] .filemaker-difference-text { padding-left: 18px; padding-right: 18px; } } /* ============================================================================ NOTA PER IL CONSOLIDAMENTO ---------------------------------------------------------------------------- Il problema di fondo resta quello segnalato nella PATCH 18: il foglio usa due convenzioni (`.componente` e `.page-x .componente`) e la seconda vince sempre. Ogni pagina ha la sua profondita' di annidamento, quindi non esiste un singolo prefisso che basti per tutte: qui servivano tre classi, su applicativi ne bastavano due. Uniformare la convenzione al consolidamento elimina questa categoria di problemi. Finche' convivono, ogni regola mobile va verificata contro la specificita' reale della regola che deve sovrascrivere — non stimata. ============================================================================ */ /* ############################################################################ # # # PATCH 20 — pagina "Analizziamo il tuo caso" # # # # Va incollato IN FONDO a style.css, DOPO la PATCH 19. # # # ############################################################################ */ /* ============================================================================ QUESTA E' LA PAGINA PIU' IMPORTANTE DEL SITO ---------------------------------------------------------------------------- Contiene l'unico form di conversione. Un problema qui non e' estetico: e' una richiesta di contatto che non arriva. PROBLEMA PRINCIPALE `.form-row` e' ancora una griglia a DUE COLONNE da 116 px l'una. Due campi affiancati larghi 116 px su un telefono sono di fatto inutilizzabili. Era previsto fin dal blocco mobile iniziale, ma la regola non ha mai avuto effetto: specificita' insufficiente (vedi PATCH 19). ALTRI PROBLEMI - Padding asimmetrici lasciati dalle patch precedenti: 16 px a sinistra contro 36-46 a destra. Il testo risulta spostato. .analisi-form 16 / 46 .analisi-intro-card 16 / 40 .analisi-step-card 16 / 36 .analisi-target-item 16 / 36 - `.analisi-step-card` ha `min-height: 270px`: spazio vuoto sotto contenuti brevi. - I checkbox misurano 18 px. Non e' un errore di layout, ma su touch sono piccoli da centrare. ============================================================================ */ @media (max-width: 820px) { /* -------------------------------------------------------------------------- A. I CAMPI DEL FORM, UNO PER RIGA -------------------------------------------------------------------------- */ body[class*="page-"] .analisi-form .form-row, body[class*="page-"] .analisi-form-section .form-row, body[class*="page-"] form .form-row { display: block; } body[class*="page-"] .analisi-form .form-field, body[class*="page-"] form .form-field { width: 100%; max-width: 100%; margin-bottom: 16px; } /* font-size 16px: sotto questa soglia iOS ingrandisce la pagina al focus del campo, e l'utente si ritrova il layout zoomato */ body[class*="page-"] .analisi-form input, body[class*="page-"] .analisi-form select, body[class*="page-"] .analisi-form textarea, body[class*="page-"] form input[type="text"], body[class*="page-"] form input[type="email"], body[class*="page-"] form input[type="tel"], body[class*="page-"] form select, body[class*="page-"] form textarea { width: 100%; max-width: 100%; box-sizing: border-box; font-size: 16px; min-height: 46px; } body[class*="page-"] .analisi-form textarea { min-height: 120px; } /* -------------------------------------------------------------------------- B. CHECKBOX PIU' FACILI DA CENTRARE Il box passa da 18 a 22 px. La label resta cliccabile per intero, quindi l'area utile e' comunque tutta la riga. -------------------------------------------------------------------------- */ body[class*="page-"] .analisi-form input[type="checkbox"], body[class*="page-"] form input[type="checkbox"] { width: 22px; height: 22px; min-height: 0; flex: 0 0 auto; } body[class*="page-"] .form-privacy-check, body[class*="page-"] label.form-privacy-check { grid-template-columns: 22px minmax(0, 1fr); gap: 12px; align-items: start; padding: 6px 0; } /* -------------------------------------------------------------------------- C. PADDING SIMMETRICI Le patch precedenti avevano corretto solo il lato sinistro. -------------------------------------------------------------------------- */ body[class*="page-"] .analisi-intro .analisi-intro-card, body[class*="page-"] .analisi-form-section .analisi-form, body[class*="page-"] .analisi-steps .analisi-step-card, body[class*="page-"] .analisi-target .analisi-target-item, body[class*="page-"] .analisi-intro-card, body[class*="page-"] .analisi-form, body[class*="page-"] .analisi-step-card, body[class*="page-"] .analisi-target-item, body[class*="page-"] .analisi-form-note { padding-left: 18px; padding-right: 18px; } /* -------------------------------------------------------------------------- D. Altezza minima delle schede passo -------------------------------------------------------------------------- */ body[class*="page-"] .analisi-steps .analisi-step-card, body[class*="page-"] .analisi-step-card { min-height: 0; } /* -------------------------------------------------------------------------- E. Il pulsante di invio a piena larghezza E' l'azione finale della pagina: deve essere impossibile mancarlo. -------------------------------------------------------------------------- */ body[class*="page-"] .analisi-form button, body[class*="page-"] .analisi-form [type="submit"] { width: 100%; min-height: 50px; font-size: 17px; } } /* ============================================================================ DA VERIFICARE A MANO DOPO L'APPLICAZIONE ---------------------------------------------------------------------------- Il CSS non puo' dire se il form FUNZIONA. Su questa pagina conviene provarlo davvero da telefono: - compilare e inviare, controllando che la mail arrivi - verificare che il campo non faccia zoomare la pagina al focus (e' quello che il font-size 16px previene) - controllare che Turnstile si veda per intero e non sbordi - verificare che i messaggi di errore, se ci sono, siano leggibili L'invio era gia' stato testato in precedenza, ma da desktop. ============================================================================ */ /* ############################################################################ # # # PATCH 21 — gli spostamenti di composizione del desktop # # # # Va incollato IN FONDO a style.css, DOPO la PATCH 20. # # # ############################################################################ */ /* ============================================================================ COSA SONO ---------------------------------------------------------------------------- Il foglio usa `transform: translate()` per rifinire la composizione del desktop: alzare un blocco di qualche pixel, allineare due colonne, far sporgere un elemento. Sono aggiustamenti visivi, non struttura. Su mobile quegli spostamenti restano, ma il layout sotto e' cambiato: .hero-analizziamo .hero-inner translateX(-220px) .page-chi-siamo ... > div:first-child translateY(-48px) .page-infrastruttura ... > div:first-child translateY(-48px) .page-hosting ... > div:first-child translateY(-32px) .page-contatti .contact-hero-inner translateY(-32px) .hero-filemaker ... > div:first-child translateY(-22px) .hero-applicativi ... > div:first-child translateY(-8px) .hosting-growth-chart translateY(18px) .applicativi-web-system-media img translateX(16px) .applicativi-technology-filemaker-content translateY(-18px) .filemaker-difference-mark translateY(-24px) DUE CONSEGUENZE 1. Su "Analizziamo il tuo caso" il translateX(-220px) porta titolo e testo dell'hero FUORI dallo schermo a sinistra: il blocco va da -196 a 127 px su un viewport di 375. E' il caso piu' grave. 2. I translateY spiegano i vuoti inseguiti nelle PATCH 11, 13 e 14: un blocco spostato in alto di 48 px lascia 48 px vuoti sotto di se'. I "48 px misteriosi" sotto il testo di chi-siamo e infrastruttura erano esattamente questo, non padding o celle fantasma della griglia. ---------------------------------------------------------------------------- NOTA: un `transform` non modifica lo spazio occupato nel flusso. L'elemento viene disegnato altrove ma continua a riservare la sua posizione originale: per questo il buco resta dove il blocco "era", ed e' invisibile a qualsiasi controllo su padding, margini e altezze. ============================================================================ */ @media (max-width: 820px) { /* -------------------------------------------------------------------------- Gli spostamenti di composizione si annullano. Su una colonna sola non hanno piu' niente da allineare. -------------------------------------------------------------------------- */ body[class*="page-"] .hero .hero-inner, body[class*="page-"] .hero .hero-inner > div:first-child, body[class*="page-"] .contact-hero .contact-hero-inner, body[class*="page-"] .hero-analizziamo .hero-inner, body[class*="page-"] .hosting-growth-chart, body[class*="page-"] .applicativi-web-system-media img, body[class*="page-"] .applicativi-technology-filemaker-content, body[class*="page-"] .filemaker-difference-mark { transform: none; } } /* ============================================================================ COSA NON VIENE TOCCATO — e perche' ---------------------------------------------------------------------------- Restano attivi i `transform` che servono su mobile: .hero .hero-bg img scale(1.7) inquadratura (PATCH 12) .hero-infrastruttura ... scale(1.25) .contact-hero-bg img scale(2.1) .nav-burger span rotate() animazione del pulsante menu .applicativi-technology-filemaker-media img perspective + rotate: effetto 3D voluto sull'immagine, non uno spostamento La differenza e' che questi trasformano l'elemento su se' stesso, mentre quelli rimossi lo spostano rispetto al layout. ---------------------------------------------------------------------------- DA CONTROLLARE DOPO L'APPLICAZIONE In console, a 375 px, su ogni pagina — deve tornare un array vuoto: [...document.querySelectorAll('*')].filter(el => { const t = getComputedStyle(el).transform; if (t === 'none') return false; const m = t.match(/matrix\(1, 0, 0, 1, (-?[\d.]+), (-?[\d.]+)\)/); return m && (Math.abs(+m[1]) > 4 || Math.abs(+m[2]) > 4); }).map(el => el.className + ' ' + getComputedStyle(el).transform) Cerca le sole traslazioni (matrice identita' con offset), quindi ignora correttamente scale e rotazioni. ============================================================================ */ /* ############################################################################ # # # PATCH 23 — scroll su "Analizziamo il tuo caso": la causa # # # # Va incollato IN FONDO a style.css, DOPO la PATCH 22. # # # ############################################################################ */ /* ============================================================================ IL PROBLEMA — e perche' nessun controllo l'aveva visto Il colpevole non e' Turnstile. E' il cerchio decorativo della card "Mettiamo ordine nelle informazioni": .analisi-intro-card::before { position:absolute; top:-28px; right:-28px; width:110px; height:110px; } La card vive dentro `.container`, che su mobile ha 28 px di padding laterale. Il `right: -28px` del cerchio annulla ESATTAMENTE quel padding: il bordo destro del cerchio cade sul bordo del viewport, con margine ZERO. Misurato in Chromium, emulazione mobile, su nove combinazioni larghezza/densita': 375 @2x · 375 @3x · 390 @3x · 393 @3x · 414 @2x 428 @3x · 430 @3x · 360 @3x · 412 @2.625x eccedenza = 0.000 px su TUTTE. Non "poco": zero netto, a ogni larghezza, perche' i due 28 px si cancellano per costruzione. E' una condizione di equilibrio instabile. Basta una frazione di pixel — arrotondamento a densita' 3x, la larghezza non intera del viewport di Chrome iOS, il rimbalzo elastico dello scroll — e il cerchio passa oltre il bordo. Sul dispositivo la frazione c'e'; nell'emulatore a larghezze intere no. TRE MOTIVI INDIPENDENTI PER CUI GLI SCRIPT NON POTEVANO TROVARLO 1. Un `::before` NON compare in `document.querySelectorAll('*')` e non ha un `getBoundingClientRect()` proprio. Ogni ciclo "elementi che sforano" e' cieco ai pseudo-elementi. Per questo tutte le verifiche elemento-per-elemento tornavano vuote. 2. `scrollWidth === clientWidth` era CORRETTO: con eccedenza 0 la pagina non sfora davvero, alle larghezze intere provate. 3. Nascondere una sezione alla volta non isola un difetto che si manifesta solo sul dispositivo: nell'emulatore, con o senza quella sezione, la misura e' identica. La conferma e' causale, non indiziaria: disattivando il solo `::before`, `.analisi-intro-card` passa da scrollWidth 345 a 317 (= clientWidth) e `.analisi-intro-inner` da 346 a 319. I 27-28 px attribuiti a Turnstile nella PATCH 22 sono questi. ---------------------------------------------------------------------------- SECONDO DIFETTO, STESSA PAGINA — l'honeypot .form-hp { position:absolute; left:-9999px; width:1px; overflow:hidden; } Il campo esca del form. L'`input` dentro resta largo 36 px e il box finisce a x = -9999. In LTR lo sforamento a SINISTRA non entra mai in `scrollWidth` e non e' raggiungibile scrollando: e' invisibile per costruzione a qualunque misura fatta finora, ed e' l'unico elemento del sito posizionato fuori schermo. Va sostituito con la tecnica sr-only, che occupa spazio zero senza creare un box fuori dal viewport. ============================================================================ */ /* ---------------------------------------------------------------------------- A — Il cerchio decorativo rientra nella card (solo mobile) Su desktop la card sta in una griglia a due colonne con spazio in abbondanza: li' il cerchio deve continuare a sporgere, quindi la regola e' confinata sotto 820 px. `overflow: hidden` e' la cintura di sicurezza per qualunque altro elemento decorativo che venisse aggiunto alla card. ---------------------------------------------------------------------------- */ @media (max-width: 820px) { body[class*="page-"] .analisi-intro-card { overflow: hidden; } body[class*="page-"] .analisi-intro-card::before { top: 0; right: 0; } } /* ---------------------------------------------------------------------------- B — Honeypot: da "fuori schermo" a "spazio zero" Nessuna media query: il difetto e' identico su desktop e mobile. `clip-path: inset(50%)` lo rende invisibile mantenendolo compilabile dai bot — che e' esattamente il suo scopo. Resta escluso dal tab (tabindex=-1 nell'HTML) e dai lettori di schermo. ---------------------------------------------------------------------------- */ .form-hp { position: absolute; left: auto; width: 1px; height: 1px; padding: 0; margin: -1px; overflow: hidden; clip-path: inset(50%); white-space: nowrap; border: 0; } /* ============================================================================ C — DA FARE NELL'HTML (non qui) In analizziamo-il-tuo-caso.php, riga 201, il div e' ancora: Va portato a: Il widget passa da 300 a 150 px e entra ovunque senza trucchi. A quel punto la PATCH 22 va RIMOSSA per intero: il suo `transform: scale(.84)` con `height: 58px; overflow: hidden` sotto i 400 px rimpicciolisce il widget proprio sull'ultimo passaggio prima dell'invio, e se Cloudflare presenta una sfida interattiva l'altezza fissa la taglia. ============================================================================ */ /* ============================================================================ VERIFICA — lo script che avrebbe trovato tutto questo Da incollare in console, in emulazione mobile, su ogni pagina. A differenza dei controlli precedenti guarda anche i pseudo-elementi, i box a sinistra e il margine residuo, non solo lo sforamento gia' avvenuto. (() => { const cw = document.documentElement.clientWidth, out = []; for (const el of document.querySelectorAll('*')) { const rc = el.getBoundingClientRect(); const n = el.tagName.toLowerCase() + (el.className && typeof el.className === 'string' ? '.' + el.className.trim().split(/\s+/).join('.') : ''); for (const w of ['::before', '::after']) { const s = getComputedStyle(el, w); if (s.content === 'none' || s.display === 'none') continue; if (s.position !== 'absolute' && s.position !== 'fixed') continue; const r = parseFloat(s.right), l = parseFloat(s.left), pw = parseFloat(s.width); const bordo = !isNaN(r) ? rc.right - r : (!isNaN(l) && !isNaN(pw) ? rc.left + l + pw : null); if (bordo !== null && cw - bordo <= 2) out.push(['PSEUDO A FILO', n + w, 'margine ' + (cw - bordo).toFixed(2) + 'px']); } if (rc.left < -1 && rc.width > 0) out.push(['BOX A SINISTRA', n, Math.round(rc.left)]); if (el.scrollWidth > el.clientWidth + 1 && el.clientWidth > 0) out.push(['SCROLLER ANNIDATO', n, el.scrollWidth - el.clientWidth]); } console.table(out); return out.length ? out.length + ' rilievi' : 'pulito'; })() Atteso su questa pagina dopo la patch: resta il solo `img` dell'hero a sinistra (e' lo `scale(1.7)` della PATCH 12, ritagliato da `.hero { overflow: hidden }`, corretto cosi') e la coppia `.form-hp` / `label` come scroller da 1 px, inerte: `overflow: hidden` non e' trascinabile al tocco. ---------------------------------------------------------------------------- SUL DISPOSITIVO Applicata la patch, se lo scroll su iPhone persiste NON serve rimettere `diagnostica-scroll.html`: quel blocco misura gli elementi, e abbiamo appena visto che gli elementi non sono il posto dove guardare. Serve invece il collegamento cablato — iPhone al Mac, Safari > Sviluppo > iPhone — e leggere `document.documentElement.scrollWidth` e `window.visualViewport.width` sulla pagina vera, sul dispositivo vero. ============================================================================ */ /* ############################################################################ # # # PATCH 24 — "Quando ha senso contattarci": il blocco che resta fermo # # # # Va incollato IN FONDO a style.css, DOPO la PATCH 23. # # # ############################################################################ */ /* ============================================================================ IL PROBLEMA Riga 5327 del foglio: .analisi-target-content { position: sticky; top: 120px; } Su desktop e' voluto e funziona: `.analisi-target-inner` e' una griglia a due colonne (`minmax(0,480px) 1fr`), il titolo resta agganciato a sinistra mentre i tre item scorrono a destra. E' il motivo per cui esiste la regola. A 820 px la griglia collassa a colonna singola (riga 6739). Lo sticky pero' resta: in tutto il foglio ci sono DUE soli `position: sticky` — la navbar e questo — e nessuna media query annulla il secondo. Non ha mai avuto un comportamento mobile. Su una colonna sola lo sticky non ha piu' niente accanto a cui restare fermo: si incolla a 120 px dall'alto e i tre item gli salgono SOTTO. Non e' scroll orizzontale ne' un elemento che sfora: e' un blocco fermo e il resto della pagina che gli passa dietro. PERCHE' NON SI POTEVA TROVARE MISURANDO IL LAYOUT Un elemento sticky non sfora niente. Non allarga il documento, non allunga la pagina, non esce dal viewport. `scrollWidth`, `clientWidth`, box model, contenitori con overflow proprio: tutto corretto, perche' non c'e' nessun difetto di dimensione. Il difetto e' nel COMPORTAMENTO ALLO SCROLL, e si vede solo confrontando due misure prese a scroll diversi — cosa che nessuna verifica statica fa. E' anche la ragione del "solo su questa pagina": e' l'unico blocco sticky di contenuto del sito. MISURA, sulla pagina reale a 375 px position calcolato sticky, top:120px -> static blocco dopo 300px scroll inchiodato a 116px -> scorre sovrapposizione con la lista dei tre item +942 px -> -24 px (nessuna) ============================================================================ */ @media (max-width: 820px) { /* Stessa soglia a cui collassa `.analisi-target-inner`: sopra gli 820 px la griglia ha due colonne e lo sticky serve, sotto no. */ body[class*="page-"] .analisi-target-content { position: static; top: auto; } } /* ============================================================================ VERIFICA Sul telefono: scorrere fino a "Quando ha senso contattarci". Il titolo e il paragrafo devono scorrere via insieme ai tre item, senza restare appesi in alto. In console, in emulazione mobile: getComputedStyle(document.querySelector('.analisi-target-content')).position // deve dare "static" Controllo generale, da rifare su ogni pagina — cerca blocchi sticky che su una colonna sola non hanno piu' senso: [...document.querySelectorAll('*')] .filter(e => getComputedStyle(e).position === 'sticky') .map(e => e.tagName.toLowerCase() + '.' + e.className) Atteso: la sola `nav`. Qualunque altra cosa compaia va valutata allo stesso modo. ---------------------------------------------------------------------------- NOTA PER IL CONSOLIDAMENTO Questa regola va tenuta ACCANTO a `.analisi-target-content` quando si fondono blocco mobile e patch, non in coda al file: desktop e mobile dello stesso componente devono stare insieme, altrimenti la prossima volta che si tocca quel blocco lo sticky torna a essere una regola senza contesto — che e' esattamente come e' nato il problema. ============================================================================ */ /* ############################################################################ # # # PATCH 25 — uniformita' delle spaziature hero # # # # Va incollato IN FONDO a style.css, DOPO la PATCH 24. # # # ############################################################################ */ /* ============================================================================ PREMESSA — la regola unica pianificata il 04/09 NON serve piu' Il piano di allora era: azzerare tutti i margini interni dell'hero e ridefinirli, per rimediare a sette valori diversi (18/28/35/42/50/77 px sopra il titolo). Rimisurato oggi sulla pagina reale a 375 px, dopo le patch 15-24: hosting · filemaker · applicativi · analizziamo 50 px contatti 50 px chi-siamo 83 px infrastruttura 125 px index (hero scura, trattamento proprio) 50 px Sei pagine su otto sono gia' identiche. Riscrivere da zero i margini di tutte le hero per correggerne due significherebbe rimettere in gioco sei pagine che funzionano. Si correggono le due, con le loro cause. LE DUE CAUSE 1. EYEBROW VUOTO — chi-siamo e infrastruttura Div senza testo e senza figli (`:empty` li intercetta entrambi), ma con `display: inline-flex` e `margin-bottom: 18px`: spingono giu' il titolo di 33 px senza mostrare nulla. NON e' un difetto mobile: quel markup sposta il titolo anche su desktop. La correzione giusta e' toglierlo dall'HTML (vedi sotto); la regola CSS qui e' la rete di sicurezza. 2. `margin-top: 42px` SULL'H1 DI INFRASTRUTTURA — riga 1517 .page-infrastruttura .hero h1 { margin-top: 42px; ... } Valore di composizione desktop, mai neutralizzato su mobile. E' il resto dei 125 px: 50 (base) + 33 (eyebrow) + 42 (questo). VERIFICATO IN PAGINA: applicando le due regole, chi-siamo passa da 83 a 50 e infrastruttura da 125 a 50. Esattamente il valore delle altre sei. ============================================================================ */ @media (max-width: 820px) { /* Un eyebrow senza contenuto non deve occupare spazio. `:empty` colpisce solo i div effettivamente vuoti: se domani ricevono un testo, la regola smette da sola di applicarsi e l'eyebrow torna visibile. */ body[class*="page-"] .hero .eyebrow:empty { display: none; } /* Gli scostamenti verticali di composizione dell'h1 non servono su una colonna sola. Stessa logica della PATCH 21 sui `transform`. */ body[class*="page-"] .hero h1 { margin-top: 0; } } /* ============================================================================ DA FARE NELL'HTML — la correzione vera dell'eyebrow In `chi-siamo.php` e `infrastruttura-cloud.php`, dentro l'hero, va eliminato il div vuoto: (chi-siamo) (infrastruttura) Toglierli sistema anche il desktop, dove oggi il titolo e' 33 px piu' in basso del dovuto su quelle due pagine. La regola `:empty` qui sopra puo' restare: non fa danno e protegge dal caso che ricompaia. ============================================================================ */ /* ============================================================================ APERTO — spazio fra titolo e sottotitolo (NON incluso in questa patch) Misurato, `margin-bottom` dell'h1 sulle otto pagine: contatti · analizziamo 0 px applicativi 20 px hosting · index 22 px filemaker 30 px chi-siamo 34 px infrastruttura 36 px Da 0 a 36 px: e' la disomogeneita' che resta dopo questa patch. Non l'ho uniformata perche' e' una scelta di resa visiva, non un difetto: toccarla cambia l'aspetto di tutte e otto le hero, comprese le sei gia' a posto. Se si decide di uniformarla, basta scegliere un valore e togliere il commento qui sotto. 24 px e' la mediana dei valori attuali, quindi lo scostamento massimo da com'e' oggi resta contenuto. @media (max-width: 820px) { body[class*="page-"] .hero h1 { margin-bottom: 24px; } } Da valutare guardando le pagine, non i numeri: contatti e analizziamo oggi sono a 0 e passerebbero a 24, che e' il cambiamento piu' visibile. ============================================================================ */ /* ============================================================================ VERIFICA In console, in emulazione mobile, su ciascuna pagina — deve dare 50: (() => { const h = document.querySelector('.hero, .contact-hero'); const b = h.querySelector('.hero-bg, picture, img').getBoundingClientRect(); return +(h.querySelector('h1').getBoundingClientRect().top - b.bottom).toFixed(1); })() Atteso: 50 su tutte e otto. La home resta a 50 con il suo trattamento proprio (immagine non separata dal testo, overlay scuro della PATCH 3). ============================================================================ */ /* ############################################################################ # PAGINE 404 / 410 — stile minimo # # Va incollato IN FONDO a style.css, DOPO la PATCH 25. # ############################################################################ */ /* Usa i token e i componenti esistenti: nessun colore, font o spaziatura inventati. Le due pagine non hanno hero, quindi serve solo il respiro verticale che l'hero darebbe. */ .errore-section { background: var(--white); padding: 96px 0 104px; } .errore-inner { max-width: 720px; margin: 0 auto; } .errore-code { display: block; margin: 0 0 18px; font-family: var(--f-title); font-size: 72px; font-weight: 800; line-height: 1; letter-spacing: -.04em; color: var(--vp); } .errore-inner h1 { margin: 0 0 22px; font-size: 46px; color: var(--text); } .errore-sub { margin: 0 0 36px; font-family: var(--f-body); font-size: 19px; line-height: 1.6; color: var(--muted); } .errore-links { margin: 0 0 56px; } .errore-mappa { padding-top: 34px; border-top: 1px solid var(--border); } .errore-mappa h2 { margin: 0 0 18px; font-family: var(--f-title); font-size: 19px; font-weight: 700; letter-spacing: .04em; text-transform: uppercase; color: var(--muted); } .errore-mappa ul { display: grid; grid-template-columns: repeat(2, minmax(0, 1fr)); gap: 12px 28px; margin: 0 0 36px; padding: 0; list-style: none; } .errore-mappa a { font-family: var(--f-body); font-size: 17px; font-weight: 500; color: var(--vp); transition: color .2s ease; } .errore-mappa a:hover { color: var(--vd); } .errore-nota { margin: 0; font-family: var(--f-body); font-size: 16px; line-height: 1.6; color: var(--muted); } .errore-nota a { color: var(--vp); font-weight: 600; } /* -------------------------------------------------------------------------- Mobile — stessa soglia degli altri componenti -------------------------------------------------------------------------- */ @media (max-width: 820px) { body[class*="page-"] .errore-section { padding: 56px 0 64px; } body[class*="page-"] .errore-code { font-size: 56px; } body[class*="page-"] .errore-inner h1 { font-size: 30px; /* stesso valore delle altre h1 su mobile */ } body[class*="page-"] .errore-mappa ul { grid-template-columns: minmax(0, 1fr); } }