/* ============================================================================
   BUSCADOR DEL HEADER - SOLO LUPA EN DESKTOP, SE ABRE POR HOVER
   ============================================================================

   QUE HACE
   --------
   En desktop (>= 768px) la barra de busqueda deja de ocupar su columna propia
   del header y queda reducida al boton de la lupa, alineado en la misma fila
   que los iconos de usuario y carrito. El campo de texto se despliega hacia la
   IZQUIERDA al pasar el mouse por encima, y se repliega al salir.

   Mobile NO se toca: todo lo de este archivo vive dentro de
   `@media (min-width: 768px)`.

   POR QUE ESTA EN UN ARCHIVO APARTE Y SE CARGA SINCRONICO
   -------------------------------------------------------
   Es una regla global del header, no de la categoria "autos a bateria", asi
   que no corresponde meterla en `autos-bateria.css`. Y va con un <link>
   comun -no con el truco `media="print" onload="this.media='all'"` que usa el
   resto del CSS no critico- porque de otro modo el header pintaria primero la
   barra de busqueda entera a 300-600px y recien despues la colapsaria: un
   salto visible del logo y de los iconos en cada carga de pagina.

   DE QUE MARKUP DEPENDE
   ---------------------
   El formulario lo renderiza la plataforma via
   `component('search/search-form', ...)` en `snipplets/header/header.tpl:57`,
   asi que su DOM no esta en el tema. Los unicos ganchos que se usan aca son
   los que el tema ya estiliza por su cuenta en `style-critical.scss`:
   `.search-container` (lo declara el propio header.tpl), el <form> que cuelga
   adentro, `.search-input` y `.search-submit-btn`. No se asume ninguna clase
   utilitaria intermedia.

   COLORES
   -------
   No se toca ni el color del icono ni el fondo del boton: quedan los nativos
   (`--header-search-btn-foreground` / `--header-search-btn-background` con
   `head-colors` activo, `--main-foreground` / `--main-background` sin el).
   Lo unico que cambia es la forma y la posicion.
   ============================================================================ */

@media (min-width: 768px) {

	:root {
		/* Lado del chip de la lupa en reposo. 40px es la medida de
		   `.utility-icon-md-big.utility-icon-md-colors`, el chip mas grande que
		   usan carrito y usuario, asi que la lupa entra en la misma escala. */
		--search-icon-size: 40px;

		/* Ancho del campo desplegado. El nativo iba de 300 a 600px; 320px
		   alcanza para la consulta tipica y, al abrirse por encima del logo
		   (ver punto 2), no necesita reservar espacio en la grilla. */
		--search-open-width: 320px;

		/* Ancho del panel de sugerencias. Es mas ancho que el campo a
		   proposito: ver el punto 5. */
		--search-suggestions-width: 560px;
	}

	/* 1) LA COLUMNA DE BUSQUEDA PASA A SER DEL ANCHO DEL ICONO
	   ------------------------------------------------------------------------
	   El header es una grilla de 3 columnas. En desktop el tema nativo le da a
	   la busqueda la columna del medio con `1fr`, pensada para una barra ancha.
	   Aca se invierte el reparto: el `1fr` pasa al logo y la columna de la
	   busqueda queda en `auto`, es decir del ancho de su contenido.

	   Esto es lo que deja la lupa pegada a los iconos de utilidades en lugar de
	   quedar flotando lejos. Sin esto, con el header fijo
	   (`settings.head_fix_desktop`) el problema se ve peor todavia: `store.js`
	   le fija al logo un ancho en px (`store.js.tpl:466-477`) y todo el espacio
	   sobrante se lo come la columna del medio, dejando la lupa a varios
	   cientos de pixeles de los demas iconos. */

	.head-row {
		grid-template-columns: 1fr auto auto;
	}

	/* El selector incluye `.logo-md-center` porque esa variante tiene su propia
	   regla nativa con mas especificidad (0,2,0) que fija `min-width: 300px` y
	   `max-width: 350px`; sin nombrarla, la busqueda seguiria reservando 300px
	   en esa configuracion del admin. */
	.search-container,
	.logo-md-center .search-container {
		grid-column: 2 / 3;
		grid-row: 1 / 2;
		width: var(--search-icon-size);
		height: var(--search-icon-size);
		min-width: 0;
		max-width: none;
		margin: 0;
	}

	.utilities-container {
		grid-column: 3 / -1;
	}

	/* 2) EL FORMULARIO SALE DEL FLUJO Y CRECE HACIA LA IZQUIERDA
	   ------------------------------------------------------------------------
	   `.search-container` ya es `position: relative` de fabrica, asi que el
	   form se ancla a el. Anclado a `right: 0` y animando el ancho, el campo se
	   abre hacia la izquierda y el borde derecho -donde esta la lupa- no se
	   mueve ni un pixel.

	   La alternativa era animar el ancho del propio `.search-container`, pero
	   eso es un item de la grilla: al expandirse empujaria el logo y los iconos
	   de carrito/usuario en cada hover. Sacando el form del flujo, la grilla
	   sigue reservando los 40px del punto 1 y nada del header se mueve.

	   Se apunta a `form` en vez de a `.search-form` a proposito: el markup lo
	   emite la plataforma y el <form> es el unico hijo de `.search-container`,
	   asi que el selector no depende de que esa clase se mantenga. */

	.search-container form {
		position: absolute;
		top: 50%;
		right: 0;
		z-index: 3;
		width: var(--search-icon-size);
		transform: translateY(-50%);
		transition: width .28s ease;
	}

	/* Los tres caminos de apertura van en REGLAS SEPARADAS, no en una lista de
	   selectores: un pseudo-selector no soportado invalida la regla entera, y
	   asi cada camino falla solo en vez de llevarse puestos a los otros. Mismo
	   criterio que el bloque de nav desktop de `autos-bateria.css`. */

	.search-container:hover form {
		width: var(--search-open-width);
	}

	/* Teclado: el input nunca se oculta con `display` ni `visibility` (ver
	   punto 3), solo con `opacity`, justamente para que siga siendo alcanzable
	   con Tab y `:focus-within` pueda abrir el campo. */
	.search-container:focus-within form {
		width: var(--search-open-width);
	}

	/* NO HAY UN TERCER CAMINO "QUEDA ABIERTO SI HAY TEXTO"
	   ------------------------------------------------------
	   Hubo una regla
	   `.search-container:has(.search-input:not(:placeholder-shown))` pensada
	   para que el campo no se replegara perdiendo la consulta a medio
	   escribir. Estaba mal: `:placeholder-shown` sigue siendo falso despues de
	   que el usuario deja de interactuar, asi que una vez escrito algo el
	   buscador quedaba abierto para siempre y no habia forma de cerrarlo salvo
	   vaciando el campo. Al tocar cualquier otra parte de la pagina seguia
	   desplegado.

	   Con los dos caminos de arriba alcanza: mientras se escribe el input
	   tiene el foco, asi que `:focus-within` lo mantiene abierto aunque el
	   mouse se vaya; y al hacer clic en cualquier otro lado el input pierde el
	   foco -el navegador se lo pasa al body-, `:focus-within` deja de valer y
	   el buscador se cierra, que es el comportamiento esperado. */

	/* 3) EL CAMPO DE TEXTO: INVISIBLE EN REPOSO, NO AUSENTE
	   ------------------------------------------------------------------------
	   Se usa `opacity` y no `display: none` / `visibility: hidden` para no
	   sacarlo del orden de tabulacion: con `display: none` el usuario de
	   teclado no tendria forma de abrir el buscador, porque `:focus-within`
	   nunca se dispararia.

	   La altura se declara explicita porque la nativa es `height: 100%` y el
	   contenedor del input no tiene altura propia; colapsado el campo a 40px,
	   ese 100% se resolveria a 0.

	   EL PADDING TAMBIEN HAY QUE ANULARLO, NO ES COSMETICO
	   -----------------------------------------------------
	   El input nativo trae 12px de padding izquierdo (`.form-control`) y 45px
	   del derecho (`.search-input`, para que el texto no pase por debajo de la
	   lupa). Con `box-sizing: border-box` -global en el tema- el ancho usado de
	   una caja nunca baja de la suma de su propio padding y borde: 12 + 45 + 2
	   = 59px. O sea que colapsado a 40px el input NO mide 40px, mide 59 y se
	   desborda 19px hacia la derecha, invisible por el `opacity: 0` pero
	   clickeable, pisando el borde izquierdo del icono de usuario. Medido en
	   Edge: contenedor 905-945, input 905-964, icono de usuario desde 961.

	   Por eso el padding se anula mientras esta cerrado -donde no hay texto que
	   separar de nada- y se restituye al abrirse, con la misma transicion que
	   el ancho del form para que entre acompanando. */

	.search-container .search-input {
		width: 100%;
		height: var(--search-icon-size);
		padding-left: 0;
		padding-right: 0;
		opacity: 0;
		transition: opacity .18s ease, padding .28s ease;
	}

	.search-container:hover .search-input {
		padding-left: var(--spacing-2);
		padding-right: var(--search-icon-size);
		opacity: 1;
	}

	.search-container:focus-within .search-input {
		padding-left: var(--spacing-2);
		padding-right: var(--search-icon-size);
		opacity: 1;
	}

	/* Cerrado, lo unico que se ve es la lupa. Si quedo texto de una busqueda
	   anterior, el boton de "borrar contenido" que el tema dibuja dentro del
	   campo (`delete_content` en header.tpl:62) quedaria flotando encima de
	   ella. Se oculta solo en el estado cerrado; abierto no se fuerza nada,
	   para no pelearle a la logica de la plataforma que decide cuando
	   mostrarlo. */

	.search-container:not(:hover):not(:focus-within) .search-empty-btn,
	.search-container:not(:hover):not(:focus-within) .search-close-btn {
		display: none;
	}

	/* 4) LA LUPA, COMO CHIP DE ICONO ALINEADO CON CARRITO Y USUARIO
	   ------------------------------------------------------------------------
	   El boton nativo es absoluto dentro del contenedor del input, con
	   `top: 1px / right: 1px` y `height: calc(100% - 2px)` -un boton pegado al
	   borde interno de una barra-. Colapsado a 40px eso queda descentrado, asi
	   que se lo lleva a ocupar el cuadrado completo y se centra el icono con
	   flex.

	   La variante `.head-colors` se nombra explicitamente porque su regla
	   nativa (0,2,0) ya pisa `top` y `right`.

	   Fondo y color del icono quedan intactos: el pedido era conservar el color
	   actual, y ademas son los dos tokens que garantizan el contraste entre el
	   icono y el fondo del boton. */

	.search-container .search-submit-btn,
	.head-colors .search-container .search-submit-btn {
		top: 0;
		right: 0;
		display: flex;
		align-items: center;
		justify-content: center;
		width: var(--search-icon-size);
		height: var(--search-icon-size);
		padding: 0;
		border-radius: var(--border-radius-full);
		transition: border-radius .28s ease;
	}

	/* Abierto, el chip vuelve al radio nativo de "boton al final de la barra":
	   redondeado solo del lado de afuera. Un circulo completo pegado al campo
	   de texto deja un hueco raro entre el borde del input y el boton. */

	.search-container:hover .search-submit-btn,
	.head-colors .search-container:hover .search-submit-btn {
		border-radius: 0 var(--border-radius-small) var(--border-radius-small) 0;
	}

	.search-container:focus-within .search-submit-btn,
	.head-colors .search-container:focus-within .search-submit-btn {
		border-radius: 0 var(--border-radius-small) var(--border-radius-small) 0;
	}

	/* 5) EL PANEL DE SUGERENCIAS NO SE ATA AL ANCHO DEL CAMPO
	   ------------------------------------------------------------------------
	   `.search-suggestions` es `width: 100%` (style-async.scss:574), o sea del
	   ancho de su contenedor: antes la barra nativa de 300-600px, ahora los
	   320px del campo desplegado. Y con el logo a la izquierda -la
	   configuracion por defecto- el tema reparte los resultados en DOS
	   columnas (`.logo-md-left .search-suggestions-list`,
	   style-async.scss:1339), una grilla pensada justamente para esa barra
	   ancha.

	   Atado a 320px cada columna queda en ~132px, de los cuales 80px se los
	   lleva la miniatura del producto: al nombre le sobran ~50px y se parte en
	   cuatro renglones. Esa es la razon por la que los resultados se ven
	   chicos y cortados.

	   La solucion es devolverle al panel el ancho para el que esa grilla fue
	   disenada, sin tocar el campo: se mantiene el buscador angosto y discreto
	   y los resultados se ven completos. Va anclado a `right: 0` -el borde de
	   la lupa- para que crezca hacia adentro de la pagina y nunca se escape
	   por la derecha. El `min()` es solo una red: en una ventana angosta el
	   panel se achica en vez de desbordar el viewport.

	EL `top` HAY QUE DECLARARLO, NO ALCANZA CON LA POSICION ESTATICA
	   ----------------------------------------------------------------
	   Al principio este bloque no declaraba `top`, dando por sentado que con
	   `top: auto` el panel se quedaba en su posicion estatica, justo debajo
	   del campo. Eso vale solo si el panel esta DENTRO del contenedor del
	   input. Si en cambio cuelga como hermano del `<form>` -que es como lo
	   arma la plataforma-, la cuenta cambia: el form es `position: absolute`
	   por el punto 2, o sea que no ocupa lugar en el flujo, y entonces la
	   posicion estatica del panel colapsa al borde superior de
	   `.search-container`. Resultado: el panel aparecia ARRIBA del campo y,
	   con su `z-index: 99999`, lo tapaba entero. La barra desaparecia apenas
	   habia resultados.

	   `top: 100%` lo baja al borde inferior de su contenedor y resuelve los
	   tres casos posibles por igual, porque los tres candidatos a contenedor
	   -`.search-container`, el `<form>` y el contenedor del input- miden los
	   mismos 40px de alto y estan alineados entre si. El `margin-top: -2px`
	   nativo sigue valiendo y lo encastra con el borde del campo. */

	.search-container .search-suggestions {
		top: 100%;
		right: 0;
		left: auto;
		width: min(
			var(--search-suggestions-width),
			calc(100vw - var(--spacing-5) * 2)
		);
	}

	/* 6) LAS SUGERENCIAS SOLO EXISTEN SI HAY ALGO ESCRITO
	   ------------------------------------------------------------------------
	   Dos situaciones en las que el panel no tiene por que estar:

	   a) El campo quedo vacio -nunca se escribio nada, o el usuario borro lo
	      que habia-. Sin consulta no hay nada que sugerir, y dejar colgando
	      los resultados de la busqueda anterior mientras se borra letra por
	      letra es exactamente lo que no se quiere.

	   b) El buscador esta cerrado. Si se escribio algo y despues se toco otra
	      parte de la pagina, el campo se repliega a los 40px de la lupa; un
	      panel de 560px colgando debajo quedaria huerfano.

	   `:placeholder-shown` es la unica forma que tiene CSS de leer si un input
	   esta vacio, y es verdadera justo cuando no hay texto. Se evalua en vivo:
	   al escribir la primera letra deja de valer y el panel vuelve, al borrar
	   la ultima vuelve a valer y el panel desaparece. Si el input de la tienda
	   no tuviera atributo `placeholder`, la regla simplemente nunca aplica y
	   el comportamiento queda como hoy: falla hacia el lado seguro.

	   POR QUE `!important` ACA Y EN NINGUN OTRO LADO DEL ARCHIVO
	   ----------------------------------------------------------
	   Quien muestra y oculta este panel es el JS de la plataforma, no el tema.
	   Si lo hace escribiendo `style="display: block"` sobre el elemento, un
	   estilo en linea le gana a cualquier selector por especifico que sea, y
	   la regla no serviria de nada. `!important` es lo unico que lo vence. Es
	   una excepcion deliberada y acotada a estas dos reglas.

	   Van en reglas SEPARADAS por el mismo criterio del punto 2: si `:has()`
	   no esta soportado, la regla (a) se invalida entera, pero la (b) -que no
	   lo usa- sigue cerrando el caso del panel huerfano. */

	.search-container:has(.search-input:placeholder-shown) .search-suggestions {
		display: none !important;
	}

	.search-container:not(:hover):not(:focus-within) .search-suggestions {
		display: none !important;
	}

	/* 7) MOVIMIENTO REDUCIDO
	   ------------------------------------------------------------------------
	   Con `prefers-reduced-motion` el campo sigue abriendose y cerrandose, pero
	   de golpe. Es un cambio de estado, no decoracion: suprimirlo dejaria el
	   buscador inaccesible. */

	@media (prefers-reduced-motion: reduce) {

		.search-container form,
		.search-container .search-input,
		.search-container .search-submit-btn {
			transition: none;
		}
	}
}