/**
 * Autocomplete AJAX — pannello suggerimenti barra di ricerca.
 * Token di progetto: Primary #32587D, brand deep #103855, accent gold
 * #BE9F56, testo #212934, secondario #667993, bordo #e2e4e7, superficie
 * #f7f8f9/#eef2f7, radius 4px input / 6px card, font Archivo (titoli) /
 * Hanken Grotesk (UI). Mobile-first: stili di base pensati per mobile,
 * override per viewport più larghi in coda al file.
 */

.fv-ac-panel {
	position: absolute;
	top: 100%;
	left: 0;
	right: 0;
	z-index: 9999;
	margin-top: 6px;
	background: #ffffff;
	border: 1px solid #e2e4e7;
	border-radius: 6px;
	box-shadow: 0 18px 44px -18px rgba(0, 0, 0, 0.35);
	max-height: 70vh;
	overflow-y: auto;
	font-family: "Hanken Grotesk", sans-serif;
}

/*
 * FIX BLOCCANTE — pannello coperto dall'hero in home.
 *
 * Diagnosi (DOM, home): `.fv-ac-panel` ha già `position:absolute` e
 * `z-index:9999` — ma un z-index su un elemento senza un proprio stacking
 * context "nuovo" viene confrontato SOLO all'interno del contesto di
 * impilamento del suo antenato più vicino che ne crea uno. Nessuno degli
 * antenati del campo di ricerca dell'header (`.fv-hdrbar__search` →
 * `.fv-hdrbar` → `.fv-hdrwrap` → `.fusion-column-wrapper` →
 * `.fusion-layout-column`) ha position diverso da static/relative SENZA
 * z-index: nessuno di loro crea un nuovo stacking context, quindi
 * `.fv-ac-panel` finisce impilato nello stesso contesto RADICE (quello
 * della pagina) dell'hero. Lì, `.fv-hero-wrap` (fratello del blocco
 * header nel markup, non un suo antenato — vedi inc/fv-hero.php) contiene
 * `.fv-hero-left{z-index:2}`: essendo un fratello che segue l'header nel
 * flusso del documento E con uno z-index positivo nello STESSO contesto
 * radice, vince sul pannello nonostante il suo z-index nominale più alto
 * (9999 è irrilevante quando il confronto avviene in un contesto diverso
 * da quello in cui l'hero vive).
 *
 * `.fv-hdrbar__search` è il markup dell'header (Fusion Builder, post
 * "Header Globale", ID 36131 — fuori scope, MAI modificato qui): questa
 * regola lo seleziona da un file CSS del tema figlio, senza toccare quel
 * post. Le impostiamo un proprio stacking context (position:relative,
 * requisito perché lo z-index abbia effetto, + uno z-index esplicito)
 * DIRETTAMENTE sull'antenato immediato del form/pannello: da qui in poi
 * `.fv-ac-panel` (z-index:9999) viene confrontato solo all'INTERNO di
 * questo nuovo contesto, dove non c'è alcun elemento .fv-hero-* con cui
 * competere, quindi vince sempre — senza bisogno di alzare ulteriormente
 * il suo z-index (9999 resta invariato, come richiesto: il problema non
 * era il valore, era l'assenza di un contesto che lo rendesse efficace).
 *
 * Valore scelto (500): ampiamente sopra `.fv-hero-left{z-index:2}` (unico
 * concorrente noto nello stesso contesto radice), ma ORDINI DI GRANDEZZA
 * sotto i menu/megamenu/flyout nativi Avada (verificato nel CSS dinamico
 * del tema: `.awb-menu__sub-arrow`, `.fusion-megamenu-wrapper`,
 * `.awb-menu_desktop.awb-menu_flyout .awb-menu__sub-ul` ecc. usano
 * z-index tra 999999997 e 999999999) — nessun rischio di coprire il menu
 * di navigazione, un eventuale dropdown Account/mega-menu o overlay del
 * carrello nativi di Avada, che restano sempre sopra a qualunque valore
 * ragionevole qui.
 *
 * L'header custom del tema (`.fv-hdrbar__actions`, markup nello stesso
 * post Fusion) usa link semplici per Account/Carrello (nessun dropdown
 * proprio in quell'header specifico), quindi qui non c'è nulla da coprire
 * in quella porzione — ma il margine verso gli z-index nativi Avada resta
 * comunque enorme per qualunque tema/header alternativo attivato in
 * futuro.
 *
 * Applicata anche al form (fallback), non solo a `.fv-hdrbar__search`:
 * copre sia l'header globale sia qualunque altro form di ricerca
 * compatibile presente in pagina (es. `.fv-search-hero-field` della
 * pagina di ricerca stessa, che vive sopra la sezione hero del post
 * "Contenuto Ricerca" — nessun conflitto noto lì, ma la stessa garanzia
 * di stacking context evita che un'eventuale sezione successiva con
 * z-index positivo la copra in futuro, senza dover intervenire di nuovo).
 */
.fv-hdrbar__search {
	position: relative;
	z-index: 500;
}

/*
 * FIX v2 — il fix precedente (position:relative + z-index:500 su
 * `.fv-hdrbar__search`) non risolveva il problema: verificato in Chrome
 * che il CSS veniva applicato correttamente, ma `.fv-ac-panel` restava
 * comunque coperto dall'hero in home. Diagnosi corretta (tracciata sulla
 * catena reale degli stacking context nel browser):
 *
 *   .fv-ac-panel            z=9999 pos=absolute
 *   FORM                    z=500  pos=relative
 *   .fv-hdrbar__search      z=500  pos=relative
 *   .fusion-builder-row ... z=10   pos=relative   <-- stacking context di riferimento (header)
 *
 *   .fusion-builder-row ... z=10   pos=relative   <-- stacking context di riferimento (hero)
 *
 * Header e hero vivono in DUE `.fusion-builder-row` fratelli DIVERSE
 * (markup Fusion Builder generato dalla pagina, non un post modificabile
 * qui), entrambe risultanti con z-index:10 nello stesso contesto padre:
 * a parità di z-index, vince chi viene DOPO nel DOM, cioè la row
 * dell'hero. Tutto ciò che sta dentro la row dell'header (compreso il
 * fix precedente su `.fv-hdrbar__search`, z-index:500) è irrilevante,
 * perché il confronto che conta avviene un livello più in alto, tra le
 * due row madri — non tra i loro discendenti.
 *
 * La row che contiene l'header (verificata via markup renderizzato:
 * home, shop, ricerca) è `<div class="fusion-fullwidth ... fv-hdr">`,
 * generata da Fusion Builder ma con classe stabile propria `fv-hdr`
 * aggiunta lato progetto — non un indice numerico tipo
 * `fusion-builder-row-2` (fragile: dipende dall'ordine con cui Fusion
 * Builder numera le row della pagina, può cambiare se la pagina viene
 * ri-salvata o riordinata nel builder). Nessuna regola CSS preesistente
 * nel tema tocca `.fv-hdr` o la row dell'hero (`.fv-home-hero`): questa
 * è la prima volta che vengono stilizzate direttamente, senza toccare i
 * post Fusion Builder (Header Globale 36131, 36140 — MAI modificati).
 *
 * Si forza qui un proprio stacking context sulla row header, con uno
 * z-index ben sopra qualunque row di contenuto (1000 è ampiamente sopra
 * il 10 osservato su entrambe le row concorrenti) ma ordini di grandezza
 * sotto i menu/megamenu nativi Avada (999999997–999999999, verificati
 * nel CSS dinamico del tema) e sotto `.fv-toast-wrap` (99999, ma comunque
 * fixed quindi già in un proprio contesto indipendente, non impattato).
 *
 * Verificato che nessun elemento con position:fixed del tema figlio (solo
 * `.fv-toast-wrap`, non impattato per lo stesso motivo) né alcun overlay/
 * modale/off-canvas vive come fratello della row header dipendente da uno
 * stacking più basso: il menu mobile (`.fv-mobilenav`) è markup statico
 * DENTRO la row header stessa, quindi sale con lei senza alterazioni di
 * visibilità relativa.
 *
 * REWORK (hardening autocomplete, dopo review): la dichiarazione
 * `.fv-hdr{position:relative;z-index:1000}` che viveva qui è stata
 * SPOSTATA in style.css, accanto alla regola `.fv-hdr{position:sticky}`
 * che ne dipende (sezione "Header sticky (M1, report UX)"). Motivo: questo
 * file (fv-search-autocomplete.css) NON viene mai caricato su cart/
 * checkout (vedi fv_search_ajax_maybe_enqueue() in fv-search-ajax.php),
 * mentre style.css è sempre caricato — lo z-index dell'header sticky
 * dipendeva quindi da un file assente su quelle pagine, lasciando
 * `.fv-hdr` con `z-index:auto` lì. Nessuna regressione per il pannello
 * autocomplete: il fix restava comunque necessario e resta applicato,
 * solo spostato di file — vedi style.css per la dichiarazione attuale.
 */

.fv-ac-group + .fv-ac-group {
	border-top: 1px solid #e2e4e7;
}

.fv-ac-row {
	display: flex;
	align-items: center;
	gap: 10px;
	padding: 12px 14px;
	cursor: pointer;
	color: #212934;
	-webkit-tap-highlight-color: transparent;
}

.fv-ac-row:active,
.fv-ac-row.is-active {
	background: #eef2f7;
}

.fv-ac-row--term .fv-ac-row__icon {
	flex: 0 0 auto;
	color: #667993;
	font-size: 14px;
	width: 18px;
	text-align: center;
}

.fv-ac-row--term .fv-ac-row__label {
	font-size: 14px;
	font-weight: 500;
}

.fv-ac-row--product .fv-ac-row__img {
	flex: 0 0 auto;
	width: 40px;
	height: 40px;
	border-radius: 4px;
	object-fit: contain;
	background: #f7f8f9;
	border: 1px solid #e2e4e7;
}

.fv-ac-row--product .fv-ac-row__img--empty {
	display: block;
}

.fv-ac-row--product .fv-ac-row__body {
	flex: 1 1 auto;
	min-width: 0;
	display: flex;
	flex-direction: column;
	gap: 2px;
}

.fv-ac-row--product .fv-ac-row__label {
	font-family: "Archivo", sans-serif;
	font-weight: 600;
	font-size: 13.5px;
	color: #212934;
	white-space: nowrap;
	overflow: hidden;
	text-overflow: ellipsis;
}

.fv-ac-row--product .fv-ac-row__price {
	font-family: "Archivo", sans-serif;
	font-weight: 700;
	font-size: 13px;
	color: #32587d;
}

/* Scrollbar minimale, coerente col resto del progetto */
.fv-ac-panel::-webkit-scrollbar {
	width: 6px;
}
.fv-ac-panel::-webkit-scrollbar-thumb {
	background: #e2e4e7;
	border-radius: 3px;
}

/* Mobile: pannello a piena larghezza rispetto al campo, righe più alte
   per il target touch (min 44px, requisito di accessibilità/usabilità
   già seguito altrove nel tema — vedi fv-hdrbar__burger in style.css). */
@media only screen and (max-width: 600px) {
	.fv-ac-row {
		padding: 13px 14px;
		min-height: 44px;
	}
	.fv-ac-panel {
		max-height: 60vh;
		border-radius: 6px;
	}
}

/* Tablet/Desktop: righe leggermente più compatte, hover esplicito
   (il tocco su mobile usa :active, non :hover). */
@media only screen and (min-width: 601px) {
	.fv-ac-row:hover {
		background: #eef2f7;
	}
}