/* CORREZIONI CHE VALGONO PER TUTTE LE VESTI, COMPRESA QUELLA DI SEMPRE.
 *
 * ⛔ PERCHE' ESISTE UN FOGLIO A PARTE. Queste correzioni stanno gia' nel
 * sorgente degli stili (`shared/styles/`), ma `app.css` e' COMPILATO: finche'
 * nessuno lo ricompila, il sorgente corretto non arriva in pagina. Ricompilare
 * 330 kB di CSS per una riga vorrebbe dire rifare tutto il foglio del sito e
 * riverificarlo: una spesa e un rischio sproporzionati.
 *
 * Questo foglio si carica DOPO `app.css` e su OGNI veste — anche sulla «A»,
 * che e' quella che sta servendo i clienti. E' l'unica cosa che il sito carica
 * in piu' rispetto a prima, ed e' meno di un kilobyte.
 *
 * ⚠️ QUANDO `app.css` VERRA' RICOMPILATO, le regole che vengono dal sorgente
 * diranno esattamente la stessa cosa del compilato e potranno essere tolte.
 * Non toglierle prima: `qa/banco_pie_di_pagina_raggiungibile.py` diventa
 * rosso se lo si fa.
 *
 * ⛔ NON TUTTO QUI DENTRO VIENE DAL SORGENTE. Dal 27 ago 2026 questo foglio
 * ospita anche correzioni NUOVE che devono valere su tutte le vesti, compresa
 * quella che serve i clienti — l'ultima sezione, quella sui comandi del
 * pagamento, e' di questo tipo e va tenuta anche dopo una ricompilazione.
 * Ogni sezione dice a quale delle due famiglie appartiene.
 */

/* --- il piè di pagina finiva sotto la barra dei comandi --------------- */
/* ⛔ IL DIFETTO, MISURATO IN PRODUZIONE IL 26 AGO 2026. La barra in basso e'
 * `position: fixed` e alta 55,5px. Lo spazio che il piè di pagina le
 * riservava era `padding-bottom: 1.5rem`, cioe' 24px: meno della meta'.
 * Risultato: TUTTI E CINQUE i link del piè di pagina — Guide, Domande
 * frequenti, Cookie Policy, Privacy Policy, Contatti — stavano a y=851-868
 * mentre la barra partiva da y=845. Coperti, e quindi impossibili da premere.
 *
 * Non e' solo scomodo: Cookie Policy e Privacy Policy devono essere
 * raggiungibili, e dal telefono non lo erano.
 *
 * ⚠️ Il tema di partenza aveva 3.5rem — l'altezza esatta della barra — e in
 * questa copia era stato abbassato a 1.5rem. Qui va a 5rem (80px), misurato
 * su tutte e sei le vesti: la barra e' alta 56px, tranne sulla veste
 * «Rivista» dove la tipografia piu' grande la porta a 60. Con 4.5rem
 * sarebbero restati 12px di margine su quella veste — troppo pochi se
 * qualcuno tiene il testo ingrandito. */
@media (max-width: 991.98px) {
  .handheld-toolbar-enabled .footer { padding-bottom: 5rem !important; }
}

/* --- i link del piè di pagina erano alti 17 pixel --------------------- */
/* ⛔ COOKIE POLICY, PRIVACY POLICY E CONTATTI SI DEVONO POTER PREMERE. Sono
 * alti quanto il loro testo — 17 pixel — e su un telefono un bersaglio così
 * si sbaglia. Non è un dettaglio estetico: sono le pagine che per legge
 * devono essere raggiungibili, e poco fa erano addirittura coperte dalla
 * barra dei comandi.
 *
 * Misurato il 26 ago 2026 su dodici schermi, dal pieghevole chiuso (280px)
 * al computer grande: sotto i 1024px risultavano sempre sotto la soglia.
 * Vale per TUTTE le vesti, compresa quella che serve i clienti adesso. */
@media (max-width: 1024px) {
  .footer .widget-list-link {
    display: inline-flex;
    align-items: center;
    min-height: 44px;
  }
}

/* --- la barra delle categorie faceva ballare la pagina ---------------- */
/* ⛔ IL LIMITE ERA SCRITTO CON L'ALTEZZA AL POSTO DELLA LARGHEZZA. In
 * `app.css` c'è `max-width: calc(100vh - 3rem)`: su un telefono in verticale
 * `100vh` vale ~900px, quindi il limite diventava 852px su uno schermo da 344
 * e non limitava più niente. La barra usciva dal viewport e la pagina
 * scorreva di lato di 2 pixel — quel tremolio laterale che fa sembrare rotto
 * un sito che funziona.
 *
 * ⚠️ QUESTA REGOLA STAVA IN `_comune.css`, CHE LA VESTE «A» NON CARICA: la
 * correzione valeva per tutte le vesti tranne quella che serve i clienti.
 * Misurato il 26 ago 2026 sul pieghevole a 344px: difetto presente solo sulla
 * veste A, e solo per questo motivo. Qui sta nel foglio che si carica SEMPRE.
 *
 * ⚠️ Le pastiglie TAGLIATE a destra invece sono volute: la barra scorre col
 * dito. Non è un difetto e non va "sistemato" mandandole a capo. */
@media (max-width: 991.98px) {
  .dj-category-related { max-width: calc(100vw - 3rem); }
}

/* --- il numero del carrello era a 10 pixel ---------------------------- */
/* È il dato che dice se il carrello è pieno: a quella misura, su un telefono,
 * non si legge. Misurato su dodici schermi, dal pieghevole chiuso in su. */
.navbar-tool-label,
.js-cart-count-value { font-size: 12px !important; }

/* --- «Preview» era un bersaglio da 15 pixel --------------------------- */
/* ⛔ È il comando che apre la scheda senza cambiare pagina, e su un telefono
 * si preme col dito: 15 pixel di altezza si sbagliano. 44px è la misura sotto
 * la quale Apple e Google danno il bersaglio per troppo piccolo.
 * ⚠️ Solo sotto i 1024px: sul computer si usa il mouse e l'altezza del testo
 * basta — allargarlo lì vorrebbe dire bucare la griglia delle schede. */
@media (max-width: 1024px) {
  .js-product-detail-modal-hook {
    display: inline-flex;
    align-items: center;
    justify-content: center;
    min-height: 44px;
  }
}

/* --- il numero di telefono nel blocco dei servizi --------------------- */
/* ⚠️ È un collegamento `tel:`, quindi si preme col dito: 44px di altezza e
 * nessuna sottolineatura finché non ci si passa sopra. Il bianco pieno lo
 * stacca dalla riga sotto, che è al 70% di opacità. */
.dj-usp__telefono {
  display: inline-flex;
  align-items: center;
  min-height: 44px;
  font-weight: 600;
  letter-spacing: .01em;
  text-decoration: none;
}
.dj-usp__telefono:hover,
.dj-usp__telefono:focus { color: #fff; text-decoration: underline; }

/* --- i comandi del pagamento restavano sotto la piega ------------------ */
/* ⚠️ CORREZIONE NUOVA, non viene dal sorgente compilato: va tenuta anche
 * quando `app.css` verra' ricompilato.
 *
 * ⛔ IL DIFETTO. Le undici pagine del pagamento mettono i comandi — «Prosegui»,
 * «Indietro», «Lista Indirizzi» — in fondo a un modulo lungo. La scheda
 * dell'indirizzo di spedizione e' alta 682 pixel e il pulsante comincia a 771:
 * su una finestra piu' bassa di 800 pixel non si vede, e chi sta comprando non
 * ha modo di sapere che la pagina si completa scorrendo. 📏 Misurato il 27 ago
 * 2026 a sei altezze: sotto gli 800 il pulsante e' sempre fuori, e su una
 * finestra di Safari con segnalibri e schede aperte — circa 505 pixel utili —
 * servivano 354 pixel di scorrimento.
 *
 * E' l'ultimo passo prima di pagare: un comando che non si vede, li', e' un
 * ordine che non parte.
 *
 * ⚠️ `sticky` e non `fixed`: la riga resta dentro la scheda e occupa il suo
 * spazio in fondo al modulo, quindi l'ultimo campo si raggiunge lo stesso
 * scorrendo. Con `fixed` avrebbe coperto per sempre l'ultima riga.
 * ⚠️ Lo sfondo pieno e il filo sopra servono: senza, i campi si vedono passare
 * sotto al pulsante.
 * ⚠️ Vale solo sul pagamento del B2C: la classe la mette
 * `b2c/shop/__layout_checkout.html`, e il B2B ha un layout suo.
 *
 * ⛔ E SOLO DA 768 PIXEL IN SU, perche' SOTTO IL SITO LO FA GIA': `app.css`
 * dichiara `.dj-checkout__actions { position: fixed; bottom: 0 }` dentro
 * `@media (max-width: 767.98px)`. Sul telefono il pulsante e' gia' ancorato,
 * e il difetto non c'era mai stato. Senza questo limite i due meccanismi si
 * sovrapponevano: i comandi restavano fissi per conto loro e il piede
 * appiccicato rimaneva in pagina VUOTO, alto 29 pixel. Visto sulla resa a
 * 375px, non dedotto — la prima stesura di questa regola non aveva il
 * limite. */
@media (min-width: 768px) {
  .dj-checkout-page .card > form > .card-footer,
  .dj-checkout-page .card > .card-footer {
    position: sticky;
    bottom: 0;
    z-index: 5;
    background: #fff;
    margin: 0 -0.5rem -1rem;
    padding: .75rem 1.5rem 1rem;
    border-top: 1px solid #e3e9ef;
    box-shadow: 0 -6px 16px -8px rgba(0, 0, 0, .18);
  }
  .dj-checkout-page .card > form > .card-footer .dj-checkout__actions,
  .dj-checkout-page .card > .card-footer .dj-checkout__actions {
    padding-top: 0 !important;
  }
}