/* 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;
  }
}

/* --- l'invito b2b schiacciato al 75% anche sul telefono --------------- */
/* ⚠️ FAMIGLIA «VIENE DAL SORGENTE»: la stessa regola sta in
 * `shared/styles/custom/_user.scss`, subito prima di `.dj-our-brands`.
 * Quando `app.css` verra' ricompilato dira' la stessa cosa e questa sezione
 * potra' essere tolta. Non prima.
 *
 * ⛔ IL DIFETTO. `app.css` dichiara
 * `.dj-banners__item--cover .dj-banners__item__content { width: 75% }`
 * a OGNI larghezza. Sul riquadro «Sei un rivenditore...» — che dal 4 set 2026
 * porta una domanda lunga al posto di «Sei un azienda?» — quel 75% lascia al
 * testo poco piu' di meta' schermo e lo manda a capo troppe volte.
 *
 * 📏 MISURATO IL 4 SET 2026, rendendo il riquadro dentro iframe di larghezza
 * fissa col CSS compilato del sito. Righe del titolo, prima -> dopo:
 *     280px (Fold chiuso)  6 -> 4        390px  3 -> 2
 *     320px                5 -> 3        412px  3 -> 2
 *     344px (Fold cover)   4 -> 3        717px  2 -> 1
 *     375px                4 -> 3       1024px  1 -> 1 (invariato, sta a 75%)
 * L'altezza del riquadro sul Fold chiuso scende da 291px a 243px.
 *
 * ⚠️ NON ERA ROTTO, ERA COMPRESSO: a nessuna delle 17 larghezze provate il
 * testo o il pulsante traboccavano, e la pagina non scorreva lateralmente
 * ne' prima ne' dopo. Non si sta chiudendo un guasto, si sta smettendo di
 * sprecare un quarto di schermo.
 *
 * ⛔ LA SOGLIA E' 992px (`lg`) E NON 768px (`md`), e la differenza si vede:
 * con `md` la resa PEGGIORAVA allargando lo schermo — a 717px il titolo
 * stava su 1 riga col 100%, a 768px risaliva a 2 col 75%. Con 992px il
 * numero di righe non risale mai. Misurato, non scelto a occhio.
 *
 * ⚠️ SOLO L'INVITO, non tutte le fasce «cover»: la classe
 * `dj-banners--invito` la mette solo `b2c/shop/_b2b_banner.html`. La fascia
 * dei banner (ETHERNA e simili) ha lo stesso schiacciamento, ma il testo lo
 * scrive il negozio dall'amministrazione e non l'ho misurato: va deciso a
 * parte. */
.dj-banners--invito .dj-banners__item--cover .dj-banners__item__content {
  width: 100%;
}
@media (min-width: 992px) {
  .dj-banners--invito .dj-banners__item--cover .dj-banners__item__content {
    width: 75%;
  }
}

/* ── I TESTI CHE IL NEGOZIO SCRIVE VANNO A CAPO ANCHE SENZA SPAZI ────────
 *
 * ⛔ IL GUASTO. 📏 Misurato il 4 set 2026 dalla verifica avversariale, nel
 * browser, col CSS compilato del sito. Una voce
 * dei servizi con dentro un indirizzo web incollato — 160 caratteri senza
 * un solo spazio, che il pannello accetta perche' sono esattamente il
 * massimo consentito — spingeva fuori il riquadro e allargava LA PAGINA
 * INTERA:
 * ⛔ E IL SINTOMO DIPENDE DALLA VESTE ACCESA, cosa che la prima stesura di
 * questo commento non diceva. 📏 Rimisurato il 4 set 2026 con la catena di
 * fogli VERA della veste «Amazon 2», quella accesa in produzione: li'
 * `_comune.css` mette `overflow-x: hidden` su `html, body`, quindi la pagina
 * NON si trascina di lato — il testo lungo esce dal riquadro e viene
 * TAGLIATO VIA, irraggiungibile. Misurato: un titolo di 80 caratteri
 * attaccati fa un elemento largo 1121px che sporge 862px oltre lo schermo di
 * un telefono da 375, con la pagina che resta larga 375.
 * ⚠️ Senza i fogli della veste (per esempio sulla veste «a») il sintomo e'
 * quello descritto prima: la pagina si allarga davvero e si trascina di lato.
 * Le due cose sono diverse e il rimedio e' lo stesso.
 * ⛔ NON RIPORTO PIU' I QUATTRO NUMERI DELLA PRIMA STESURA (2047, 1720, 194,
 * 1131): venivano da una misura fatta senza i fogli della veste, e la
 * verifica del 4 set non e' riuscita a riprodurli restando dentro i limiti
 * dei campi (titolo 80 caratteri, testo 160). Un numero che non si sa piu'
 * rifare vale meno di nessun numero.
 * `overflow-wrap` valeva `normal` su h2, h6 e p, e nel blocco dei servizi
 * nessun antenato ritaglia.
 *
 * ⚠️ NELL'INVITO NON TRABOCCAVA: `.dj-banners__item` ha `overflow: hidden`,
 * quindi lo stesso testo veniva TAGLIATO VIA in silenzio — il negozio
 * scriveva 255 caratteri, sul sito ne vedeva meno, e niente glielo diceva.
 * Serve anche li', per la ragione opposta.
 *
 * ⛔ PERCHE' ADESSO E PRIMA NO: fino al 4 set 2026 quei testi erano scritti
 * nel template, quindi nessuno poteva metterci dentro un indirizzo. Da
 * quando li scrive il negozio, l'ingresso non lo decide piu' chi scrive il
 * codice.
 *
 * ⚠️ `anywhere` e non `break-word`: `break-word` non riduce la larghezza
 * minima della colonna, e in una griglia come questa il riquadro resterebbe
 * comunque largo quanto la parola. */
/* ⛔ I TAG QUI SOTTO DEVONO ESSERE QUELLI CHE IL TEMPLATE EMETTE DAVVERO, e
 * per un po' non lo sono stati: la riga diceva `.dj-usp h6` mentre lo stesso
 * lavoro, poche ore dopo, aveva cambiato il titolino della voce in `h3` per
 * rimettere a posto la gerarchia dei titoli. 📏 Misurato il 4 set 2026 dalla
 * verifica: l'`h3` restava largo 751px contro i 252px che avrebbe avuto con
 * la regola — cioe' proprio il titolo per cui la regola e' stata scritta era
 * l'unico rimasto scoperto. Una correzione che ne disattiva un'altra, e
 * nessuno dei due file lo diceva.
 * ⚠️ ADESSO LO CONTROLLA UN BANCO: `qa/banco_testi_dei_blocchi_fissi.py`
 * confronta i tag di questo elenco con quelli che il template rende, invece
 * di limitarsi a cercare la stringa nel foglio. */
/* ⛔ E VALE PER TUTTA LA FASCIA DEI BANNER, non per il solo invito. Il
 * selettore diceva `.dj-banners--invito`, ma `overflow: hidden` sta su
 * `.dj-banners__item`, che e' la scheda di ENTRAMBI i blocchi: quello dei
 * banner e quello dell'invito escono uno accanto all'altro in home, con la
 * stessa struttura e gli stessi campi scritti dal negozio, e solo il secondo
 * era coperto. ⚠️ Lo riporta la verifica sulla convivenza dei blocchi del
 * 5 set 2026, che ha reso la home intera coi fogli veri a 375px: nel banner
 * il titolo di 80 caratteri veniva tagliato di 183px, il sottotitolo di
 * 234px, e il pulsante sporgeva di 97px OLTRE il bordo dello schermo — con
 * il testo tagliato via invece che mandato a capo, perche' `html, body`
 * hanno `overflow-x: hidden`. Il banner ha anche MENO spazio dell'invito
 * (75% contro 100%), quindi si rompe PRIMA del blocco che era stato
 * corretto. Due schede identiche accanto, due comportamenti opposti.
 * ⚠️ I titoli dei banner sono `h5` come quelli dell'invito: il selettore non
 * cambia, cambia solo il contenitore da cui parte. */
.dj-usp h2,
.dj-usp h3,
.dj-usp p,
.dj-banners h5,
.dj-banners p,
.dj-banners .btn {
  overflow-wrap: anywhere;
}

/* ⛔ E IL PULSANTE VUOLE ANCHE `white-space`, se no la riga qui sopra su di
 * lui NON FA NIENTE: `.btn` di Bootstrap porta `white-space: nowrap`, e
 * `overflow-wrap` non ha nessun effetto su un elemento che non va a capo.
 * 📏 Misurato il 4 set 2026 a 375px con la veste accesa: una scritta di 49
 * caratteri rende il pulsante largo 365px, che sborda di 44px dalla scheda —
 * e siccome `.dj-banners__item` ha `overflow: hidden`, la scritta viene
 * tagliata invece che andare a capo. Il pannello quella scritta la accetta:
 * il campo arriva a 50 caratteri.
 * ⚠️ Con `white-space: normal` lo stesso pulsante misura 297px su due righe e
 * sta dentro la scheda. Sotto i 34 caratteri non cambia niente. */
.dj-banners .btn {
  white-space: normal;
  max-width: 100%;
}