/* Blocco "modello" riusabile STRIP (vedi includes/blocks.php). Non legato a una pagina in particolare: qualunque pagina che lo abiliti dai campi di wp-admin ottiene lo stesso markup/stile. Sezione orizzontale generica: sfondo (immagine e/o colore) opzionale, larghezza piena o contenuta, padding regolabile, altezza piena schermo opzionale (fullheight), righe di blocchi (fields['rows'], vedi nma_render_strip_block() in includes/blocks.php) disposte in orizzontale - responsive, verticali sotto una certa larghezza. Le custom property (px scelti in wp-admin, qui solo un default di rispetto se mancassero) sono inline style: padding-x, padding-y e position-y sulla sezione (.strip), gap-x/gap-y invece per riga (sul singolo .strip__row, non generali per tutto lo strip: righe diverse possono avere gap diversi). padding-top/padding-bottom/margin-top/margin-bottom: DOPPIO var() a cascata, non un default letterale come padding-x sopra. Campo del singolo Strip vuoto (vedi nma_render_strip_block() in includes/blocks.php) = niente inline style per --strip-padding-top ecc. = si legge il secondo var(), --strip-default-*, scritto in :root da nma_theme_settings_strip_defaults_css() (includes/theme-settings.php) dal valore impostato in Impostazioni Tema > Spaziatura Strip (0 finche' nessuno la tocca). Campo dello Strip valorizzato invece scrive --strip-padding-top ecc. inline: quello vince sempre, il default resta ignorato per quello Strip. Questa regola vale per Desktop/Tablet: sotto il breakpoint Mobile (editabile in Impostazioni Tema > Breakpoint) nma_theme_settings_strip_responsive_css() ridichiara le stesse 4 proprieta' dentro un @media, con un var() IN PIU' davanti che legge --strip-padding-top-mobile ecc. (stessa fonte, colonna "Mobile" del campo/dell'impostazione generale) prima di ricadere su questa stessa regola - vedi quella funzione in includes/theme-settings.php per la catena completa. */ .strip { position: relative; box-sizing: border-box; padding-top: var(--strip-padding-top, var(--strip-default-padding-top, 0px)); padding-bottom: var(--strip-padding-bottom, var(--strip-default-padding-bottom, 0px)); padding-left: var(--strip-padding-x, 0px); padding-right: var(--strip-padding-x, 0px); margin-top: var(--strip-margin-top, var(--strip-default-margin-top, 0px)); margin-bottom: var(--strip-margin-bottom, var(--strip-default-margin-bottom, 0px)); } /* "Piena larghezza": esce da .entry-content (max-width:720px, vedi base.css) con width:100vw + margin-left negativo - nessuna regola WP con !important la puo' piu' schiacciare, e' tema classico. 100vw include SEMPRE la scrollbar verticale (specifica CSS): quando questa riserva spazio la sezione risulta un po' piu' larga dello spazio davvero visibile. Nessun problema: 100vw non e' MAI piu' stretto del vero (a differenza di una larghezza calcolata via JS/clientWidth, intera - niente parte decimale, poteva lasciare un filo di sfondo body visibile ai lati, specie per .strip__gradient che eredita 1:1 le dimensioni di questa sezione e il cui punto finale cadrebbe corto del bordo destro vero). L'eventuale eccesso (scrollbar) e' tagliato da overflow-x:hidden su html,body (base.css): mai un buco, al massimo overscan invisibile. */ .strip--full { width: 100vw; margin-left: calc(50% - 50vw); } /* "Larghezza contenuto": resta nel flusso normale di .entry-content, niente full-bleed. */ .strip--contenuto { width: 100%; } /* Checkbox "Altezza piena schermo" in wp-admin: la sezione occupa tutto lo spazio VISIBILE sotto l'header quando e' a fuoco, righe centrate in automatico (nessuna percentuale impostata in wp-admin, vedi 'position_y' in includes/blocks.php). Con una percentuale esplicita interviene invece .strip--rows-positioned sotto: .strip__rows esce dal flusso (position:absolute) e questo justify-content non ha piu' alcun effetto su di lei. min-height:100vh da solo sarebbe scorretto: l'header e' sticky (sempre visibile, vedi .site-header in header.css) e "ruba" --site-header-height px alla viewport per tutto il tempo (di piu' se loggati: include anche la barra admin di WordPress, altrettanto fissa in cima), ma 100vh si misura dalla cima della viewport (y0) a prescindere - un blocco fullheight risulterebbe piu' alto dello spazio che l'utente vede davvero sotto header+barra admin, l'eccesso finirebbe fuori schermo. --site-header-height e' impostata via JS (due ResizeObserver, su .site-header e su #wpadminbar se presente - misurano l'altezza reale invece di indovinare i breakpoint di WP, vedi assets/js/nav-responsive.js): fallback 0px se JS non ancora girato (prima esecuzione, no-JS) o niente header sopra. */ /* Pavimento minimo per QUALSIASI strip con righe posizionate a percentuale ('position_y', vedi .strip--rows-positioned .strip__rows sotto): quella regola mette .strip__rows in position:absolute, quindi esce dal flusso e NON contribuisce piu' all'altezza automatica di .strip - senza questa riga .strip restava alto solo quanto il suo padding (contenuto delle righe completamente ignorato), il contenuto "scappava" sotto, sovrapposto al blocco successivo. --strip-rows-required-height e' impostata via JS (ResizeObserver su .strip__rows, vedi assets/js/strip-fullheight.js) = offsetTop + offsetHeight di .strip__rows + padding-bottom di .strip, cioe' lo spazio VERO che le righe occupano dato il loro posizionamento attuale. Deve stare PRIMA di .strip--fullheight qui sotto nel foglio: se un elemento ha entrambe le classi, quella regola (dopo, stessa specificita') deve vincere lei - la sua formula con max() include gia' questo pavimento, oltre al piano viewport. */ .strip--rows-positioned { min-height: var(--strip-rows-required-height, 0px); } .strip--fullheight { /* --strip-peek-next (facoltativo, campo "Intravvedi blocco successivo di" in wp-admin): sottrae altri px al min-height cosi' l'inizio del blocco successivo sbircia in basso, sotto lo strip a fuoco. Il max() con --strip-rows-required-height (0px se non e' un .strip--rows-positioned, vedi sopra - quindi qui sotto non cambia nulla per il caso comune "fullheight senza percentuale esplicita") impedisce che il peek "mangi" spazio che il contenuto posizionato sta davvero usando: il piano viewport-meno-peek resta il minimo preferito, ma se le righe posizionate richiedono di piu' vince quello, mai sotto. 100vh (prima riga, fallback per browser senza supporto svh) su mobile e' la viewport "grande" (barra indirizzi nascosta) e su molti browser si RICALCOLA durante lo scroll man mano che la barra si nasconde - il blocco cresce in tempo reale inseguendo lo scroll, "mangiandosi" il peek a prescindere da quanto e' grande (mai un problema su desktop, ne' simulando da devtools ridimensionando la finestra: li' 100vh e' fisso, nessuna barra dinamica). 100svh (seconda riga, vince per cascata sui browser che la supportano) e' la viewport PICCOLA, barra sempre considerata visibile, valore stabile che non insegue lo scroll. */ min-height: max(calc(100vh - var(--site-header-height, 0px) - var(--strip-peek-next, 0px)), var(--strip-rows-required-height, 0px)); min-height: max(calc(100svh - var(--site-header-height, 0px) - var(--strip-peek-next, 0px)), var(--strip-rows-required-height, 0px)); display: flex; flex-direction: column; justify-content: center; } /* Percentuale esplicita in wp-admin ('position_y', facoltativa): il TOP della riga si ancora a --strip-position-y dell'altezza dello strip, niente centratura. position:absolute e non relative apposta: un 'top' in percentuale su un elemento in flusso normale/relative non si risolve se il contenitore non ha un'altezza dichiarata esplicitamente con la proprieta' 'height' (min-height non conta per questa regola CSS, resta "auto" cioe' 0 - il bug per cui le righe finivano in cima invece che alla percentuale scelta) - un elemento absolute invece la risolve correttamente contro il box gia' calcolato del contenitore, anche se quel box viene da min-height. left/right replicano --strip-padding-x perche' il contenitore di un absolute e' il "padding box" dell'antenato posizionato (.strip, position:relative), che ignorerebbe altrimenti il padding orizzontale della sezione. */ .strip--rows-positioned .strip__rows { position: absolute; left: var(--strip-padding-x, 0px); right: var(--strip-padding-x, 0px); top: var(--strip-position-y, 0%); } .strip__bg { position: absolute; inset: 0; background-size: cover; background-position: center center; background-repeat: no-repeat; } /* Sfondo di SEZIONE in modalita' "SVG" (bg_source='svg', vedi nma_render_strip_block() in includes/blocks.php): stesso identico principio di .strip__block-bg--svg piu' sotto (sfondo di un singolo blocco), qui applicato a tutta la sezione - .strip__bg sopra resta invariato (position:absolute;inset:0), qui solo la stampa cambia da background-image CSS a markup SVG vero, quindi deve riempire il contenitore da solo. */ .strip__bg--svg { display: flex; } .strip__bg--svg .nma-svg-inline { width: 100% !important; height: 100% !important; } /* Velo gradiente opzionale (fields['gradient_*'], vedi nma_render_strip_block() in includes/blocks.php): niente z-index apposta, sta nel flusso di stacking "auto" come .strip__bg sopra - z-index:1 su .strip__rows sotto crea gia' un contesto separato che lo sovrasta a prescindere. Basta che nell'HTML venga dopo .strip__bg (dove infatti e' scritto) perche' un elemento position:absolute successivo con z-index:auto dipinga sopra al precedente. */ .strip__gradient { position: absolute; inset: 0; } /* Niente gap qui: la distanza verticale fra righe e' interamente affidata al margin-top/margin-bottom di ciascuna .strip__row (inline style, vedi nma_render_strip_block() in includes/blocks.php) - un gap fisso qui si sommerebbe al margine invece di essere sostituito da lui, raddoppiando lo spazio anche quando il margine e' impostato a 0. */ .strip__rows { position: relative; z-index: 1; display: flex; flex-direction: column; } /* Una riga di blocchi: orizzontale su schermi larghi (gap --strip-gap-x), verticale sotto la soglia qui sotto (gap --strip-gap-y invece - separato perche' in colonna i blocchi sono spesso piu' alti che larghi). Le due variabili sono inline style su QUESTO .strip__row (una riga = un gap proprio, scelto in wp-admin per quella riga - vedi nma_render_strip_row_fields() in includes/meta-boxes.php e nma_render_strip_block() in includes/blocks.php), non sulla sezione. Un .strip__row per riga salvata in wp-admin, un .strip__block per blocco dentro. */ /* flex-wrap:wrap necessario insieme a min-width:min-content su .strip__block sotto: senza, flex-shrink stringe i blocchi oltre il loro contenuto (overflow:hidden su .strip__block azzera il min-width automatico che normalmente lo impedirebbe) e il contenuto che non puo' andare a capo (es. una parola lunga in un titolo) viene tagliato invece che spostare il blocco a riga nuova. */ /* justify-content:space-evenly non ha alcun effetto quando i blocchi non hanno un max-width proprio (min_width/max_width, campi per-blocco, vedi nma_render_strip_row_block() in includes/blocks.php): flex-grow:1 su .strip__block sotto consuma comunque TUTTO lo spazio disponibile sulla riga, zero spazio libero da distribuire. Diventa visibile solo quando un blocco ha una larghezza massima impostata e flex-grow non puo' piu' crescere oltre: lo spazio che avanza si distribuisce come gap piu' largo fra i blocchi, o come margini uguali ai due lati se il blocco e' unico nella riga (cioe' lo centra) - stesso CSS per entrambi i casi, nessuna classe/logica condizionale server-side serve. */ .strip__row { display: flex; flex-wrap: wrap; justify-content: space-evenly; gap: var(--strip-gap-x, var(--strip-gap-x-default, 24px)); } /* Un blocco dentro una riga: immagine di sfondo opzionale (.strip__block-bg, sotto) e/o testo opzionale (.strip__block-text, vedi nma_render_strip_row_block() in includes/blocks.php) - un blocco senza nessuno dei due resta comunque nel layout (riquadro vuoto, e' uno slot voluto). overflow:hidden serve a .strip__block-bg (inset:0 la farebbe uscire dagli angoli arrotondati/dal riquadro altrimenti). */ .strip__block { position: relative; flex: 1 1 0; /* min-width esplicito (vedi commento su .strip__row sopra): overflow:hidden qui sotto azzererebbe altrimenti il min-width automatico del flex item, permettendogli di stringersi oltre il contenuto invece di andare a capo con flex-wrap. min-content = larghezza del pezzo piu' largo che non puo' spezzarsi (una parola, un'immagine) - il blocco non si stringe oltre quello, va a riga nuova prima. */ min-width: min-content; min-height: 80px; /* Fallback: nma_render_strip_row_block() (includes/blocks.php) scrive sempre padding-top/padding-bottom inline (padding_y, editabile in wp-admin, default 24px) - questo valore conta solo per un eventuale markup senza quello style inline. */ padding-top: 24px; padding-bottom: 24px; /* padding-left/right NON in un valore letterale (a differenza di padding-top/bottom sopra): leggono invece --strip-block-pad-x, che nma_render_strip_row_block() imposta sempre inline (padding_x) ma SENZA mai dichiarare padding-left/right stessi come proprieta' inline dirette. Necessario per il full-bleed "quando in colonna" (checkbox 'edge_on_stack' sullo stesso blocco): un inline style vince sempre su qualunque regola successiva di questo foglio (anche dentro un @media), quindi .strip__block--edge-on-stack{padding-left:0} (vedi nma_theme_settings_strip_responsive_css() in includes/theme-settings.php) non riuscirebbe mai a batterlo se padding-left fosse anche lui inline - qui invece SOLO la custom property lo e', la proprieta' CSS vera e propria resta libera di essere sovrascritta normalmente, senza !important. */ padding-left: var(--strip-block-pad-x, 24px); padding-right: var(--strip-block-pad-x, 24px); overflow: hidden; /* --strip-block-bg: var CSS impostata inline da nma_render_strip_row_block() in includes/blocks.php (non background-color diretto: un inline style vincerebbe sempre su .strip__block--hover:hover sotto, vedi commento li' in blocks.php) - transparent di default, nessun cambiamento visivo per i blocchi senza colore di sfondo. */ background-color: var(--strip-block-bg, transparent); } /* Checkbox "Adatta alla larghezza del contenuto (fit-content)" (vedi nma_render_strip_row_block_fields() in includes/meta-boxes.php): sostituisce flex:1 1 0 sopra (che fa crescere il blocco a riempire tutta la riga) con flex:0 1 auto - grow:0 non lo fa piu' crescere oltre il proprio contenuto, shrink:1 lo lascia comunque restringersi se la riga e' troppo stretta (niente overflow), basis:auto con nessuna larghezza esplicita impostata fa si' che il motore flex lo dimensioni sul contenuto stesso (il suo "max-content size"). min-width/max-width (style inline, vedi nma_render_strip_row_block()) restano comunque validi insieme: limitano solo l'estremo, la dimensione base resta quella del contenuto. */ .strip__block--fit-content { flex: 0 1 auto; } /* Contenuto "Slider" (vedi nma_render_strip_row_block_content() in includes/blocks.php, riusa nma_render_slider_block() a peso zero, .slider-block finisce diretto figlio di .strip__block, nessun wrapper). Il min-width:min-content sopra e' pensato per non spezzare una parola/immagine singola a meta', ma uno slider in variante --loop (assets/css/slider.css) ha le slide in riga flex SENZA wrap e SENZA shrink (flex:0 0 auto, necessario perche' e' JS a raggrupparle in "pagine" scorrevoli via .slider-block__track{overflow-x:auto}, non il flex-shrink) - il min-content di quella riga e' la somma di TUTTE le slide, non la piu' larga. Con min-width:min-content ereditato, .strip__block si rifiutava di stringersi sotto quella somma e usciva dal viewport invece di lasciare che lo slider gestisse da solo lo scroll orizzontale interno. Basta in riga (flex-direction:row, il default): main-axis e' la larghezza, flex:1 1 0 con min-width:0 la ridistribuisce correttamente da sola. Sotto il breakpoint mobile pero' (.strip__row diventa flex-direction:column, vedi nma_theme_settings_strip_responsive_css() in includes/theme-settings.php) serve un width:100% ESPLICITO in piu' - vedi commento li' per il perche' (quirk di align-items:stretch sul cross-axis con overflow:hidden + flex-basis:auto). */ .strip__block:has(> .slider-block) { min-width: 0; } /* Colore hover facoltativo (--strip-block-bg-hover, inline style): classe presente solo se il campo e' compilato, quindi nessuna transizione/hover altrimenti. Se "Colore di sfondo" base e' vuoto (--strip-block-bg mai impostata, resta sul transparent di default sopra) lo sfondo compare solo durante l'hover. */ .strip__block--hover { transition: background-color 0.3s ease; } .strip__block--hover:hover { background-color: var(--strip-block-bg-hover); } /* Ingrandimento leggero al passaggio del mouse (checkbox 'hover_scale', nma_render_strip_row_block() in includes/blocks.php): classe presente solo se spuntata, quindi nessuna transizione/hover altrimenti. transform:scale invece di width/height - non partecipa al layout flex della riga, i blocchi vicini in .strip__row non si spostano quando questo cresce. z-index sale SOLO durante l'hover cosi' il blocco ingrandito si sovrappone ai vicini invece di finirci sotto, ma torna al livello normale a riposo (nessuna sovrapposizione indesiderata quando nessuno e' in hover). */ .strip__block--scale { transition: transform 0.3s ease; } .strip__block--scale:hover { transform: scale(1.03); z-index: 2; } .strip__block-bg { position: absolute; inset: 0; z-index: 0; background-position: center center; background-repeat: no-repeat; } /* Sfondo in modalita' "SVG" (bg_source='svg', vedi nma_render_strip_row_block() in includes/blocks.php): qui .strip__block-bg non e' un background-image CSS ma un contenitore che stampa l'output dello shortcode [nma_svg] (.nma-svg-inline, vedi assets/css/svg-library.css) - quel wrapper di default segue il font-size (1em, pensato per un uso "a icona" nel testo), qui invece deve SEMPRE riempire tutto il blocco: width/height:100% con !important (stesso principio gia' documentato altrove in questo file per un valore che un inline style o un contesto diverso altrimenti vincerebbe) perche' e' solo QUESTO contesto a richiedere il comportamento diverso dallo stesso identico markup. */ .strip__block-bg--svg { display: flex; } .strip__block-bg--svg .nma-svg-inline { width: 100% !important; height: 100% !important; } .strip__block-text { position: relative; z-index: 1; /* NIENTE overflow-x qui (era overflow-x:auto): impostarlo su questo contenitore, che avvolge OGNI testo (titoli/paragrafi compresi, non solo tabelle), forza per spec anche overflow-y a diventare auto - con scrollbar classiche (non overlay, es. mouse esterno su macOS) la barra orizzontale ruba spazio in altezza al box e fa scattare pure una barra verticale spuria, su testo qualsiasi, senza bisogno di contenuto alto. Scroll orizzontale per tabelle larghe ora vive solo su .txc-table (vedi assets/css/text-formats.css), non qui. */ } .strip__block-text p:last-child { margin-bottom: 0; } /* Stesso motivo del :last-child sopra ma sul lato opposto: senza questo il margin-top di default browser (1em) resta sul primo

e si SOMMA a qualunque padding-top messo a mano attorno al testo (es. un elenco con linee separatrici via CSS Custom, .titolo-big o .testo-medium con padding simmetrico) - spazio sopra sempre maggiore di quello sotto anche con padding identico nelle due direzioni, bug non visibile in wp-admin dove .txc-wrap .tiptap p azzera gia' margin-top (textarea-custom.css). */ .strip__block-text p:first-child { margin-top: 0; } /* Stesso identico motivo delle due regole su p sopra, ma per liste puntate/numerate (ul/ol): margine di default browser (1em) mai azzerato altrove per questi due tag - ne' qui ne' in assets/css/text-formats.css (quel file tocca solo list-style/padding-left, mai margin, vedi .txc-richtext ul/ol li'), quindi un elenco primo o ultimo elemento del blocco portava lo stesso scarto sopra/sotto gia' visto sui paragrafi (es. un elenco con linee separatrici via CSS Custom, bordo/padding dei

  • perfettamente simmetrico ma margine dell'