/* ===================================================================================
   UEB Tienda — puente con el marcado de WooCommerce
   ===================================================================================
   Todo lo que WooCommerce imprime él mismo y que el tema no ha reescrito a mano (avisos de
   woocommerce_before_single_product / wc_print_notices()). single-product.php y
   content-product.php rehacen el resto del marcado, así que este archivo se queda pequeño
   a propósito: solo lo que de verdad puede llegar a imprimirse sin pasar por una plantilla
   del tema.

   Se encola SOLO con WooCommerce activo y DESPUÉS de las seis capas globales
   (inc/assets.php), así que puede corregir cualquiera de ellas sin recurrir a !important.
   =================================================================================== */

/* ==================================================================================
   AVISOS
   ================================================================================== */

/* Los avisos de éxito los eleva liftNotices() (ueb-chrome.js) al toast, que es donde el
   usuario está mirando después de pulsar un botón, y el cajón de carrito se abre solo tras el
   redirect. Ahí, mostrar además la caja de WooCommerce es un tercer aviso redundante, y por eso
   se oculta VISUALMENTE con la técnica de .screen-reader-text (base.css) y no con display:none:
   un lector de pantalla sigue anunciándolo.

   ⚠️ Ojo con lo que esto ocultaba de más (arreglado justo debajo): liftNotices() se ejecuta UNA
   vez, en DOMContentLoaded, y sobre el PRIMER .woocommerce-message del documento. Todo lo que no
   cumpla esas dos condiciones quedaba invisible y sin sustituto:

     · los avisos que llegan por AJAX en la página del carrito — «Producto eliminado. ¿Deshacer?»
       (con el enlace de deshacer dentro, o sea funcionalidad perdida, no solo texto),
       «Cupón aplicado», «Carrito actualizado»: cart.js reemplaza el bloque .woocommerce entero
       después de que liftNotices() ya haya pasado;
     · un SEGUNDO bloque .woocommerce-message del documento. Los avisos de una misma llamada a
       wc_print_notices() van todos como <li> del mismo <ul>, así que el toast se los lleva
       juntos; pero una plantilla que llame a wc_print_notice() por su cuenta emite otro <ul>
       aparte, y ese ya no lo ve nadie. */
.woocommerce-message {
	position: absolute;
	width: 1px;
	height: 1px;
	padding: 0;
	margin: -1px;
	overflow: hidden;
	clip-path: inset(50%);
	white-space: nowrap;
	border: 0;
}

/* Los errores SÍ se quedan visibles donde WooCommerce los imprime: suelen señalar un campo
   concreto (variación no elegida, stock insuficiente) y verlos en contexto es lo que importa
   (ver la nota de liftNotices() en ueb-chrome.js). */
.woocommerce-error,
.woocommerce-info {
	list-style: none;
	margin: 24px auto;
	/*
	 * `width` fijo, no solo `max-width`: wc_print_notices() imprime en `.woocommerce-notices-
	 * wrapper`, que NUNCA está dentro de un `.wrap` (ver checkout/form-checkout.php — el aviso
	 * de checkout lo imprime ya el shortcode ANTES de que la plantilla del tema llegue a abrir
	 * su `.wrap`; en el resto de páginas tampoco hay un `.wrap` de por medio). `.wrap` mete su
	 * `padding: var(--pad)` DENTRO de su propia caja, así que el texto de la página (el h1,
	 * etc.) queda metido 40px hacia dentro de un borde que nunca se pinta. Con SOLO
	 * `max-width: var(--wrap)` el aviso reproducía ese mismo ancho máximo, pero sin ningún
	 * `.wrap` exterior que le reste el padding antes: por debajo de 1440+80px de viewport (la
	 * inmensa mayoría de pantallas reales) `max-width` no llega a limitar nada y el aviso pasa
	 * a ocupar el 100% de `.entry-content`, con su BORDE pegado al borde de la página — 40px
	 * más afuera que donde arranca el texto del resto del contenido, en CUALQUIER viewport, no
	 * solo en uno ancho. `width: calc(100% - 2*var(--pad))` fuerza ese margen de --pad a los
	 * dos lados siempre, y `max-width` de refresco solo entra a partir de pantallas enormes,
	 * para no crecer más que la columna de contenido de cualquier `.wrap`. */
	width: calc(100% - (2 * var(--pad)));
	max-width: calc(var(--wrap) - (2 * var(--pad)));
	padding: 16px calc(var(--pad) - 6px);
	border: 1px solid var(--danger);
	border-left-width: 3px;
	border-radius: var(--radius);
	background: var(--danger-soft);
	color: var(--ink);
	font-size: 14px;
	line-height: 1.5;
}

/* El informativo no es un error: mismo formato, pero en el acento de marca en vez de rojo.
   Sobre fondo claro el rojo pálido de --danger-soft es perfectamente legible, cosa que en
   el diseño oscuro anterior no habría funcionado. */
.woocommerce-info {
	border-color: var(--accent-strong);
	background: var(--accent-soft);
}

/* DESTAPADO donde el aviso de éxito es la única voz: carrito, checkout y Mi cuenta (clases reales
   de wc_body_class(), wc-template-functions.php:343-356), que es donde llegan los avisos por AJAX
   y los que traen un enlace accionable dentro. Y a partir del segundo bloque de avisos del
   documento, porque el toast solo se lleva el primero.

   Hay que deshacer UNA A UNA las declaraciones del bloque sr-only de arriba: volver a declarar el
   aspecto no basta, `position:absolute` y `clip-path` seguirían aplicándose. La especificidad
   (0,2,0) frente a (0,1,0) hace el resto, así que el orden en el archivo da igual. */
.woocommerce-cart .woocommerce-message,
.woocommerce-checkout .woocommerce-message,
.woocommerce-account .woocommerce-message,
.woocommerce-message + .woocommerce-message {
	position: static;
	width: auto;
	height: auto;
	overflow: visible;
	clip-path: none;
	white-space: normal;
	list-style: none;
	margin: 24px auto;
	/* Mismo motivo que en `.woocommerce-error`/`.woocommerce-info` un poco más arriba: sin
	   `.wrap` propio alrededor, y sin que `max-width` por sí solo baste por debajo de los
	   ~1520px de viewport, hay que fijar `width` para que el margen de --pad se respete a
	   cualquier tamaño de pantalla, no solo en las enormes. */
	width: calc(100% - (2 * var(--pad)));
	max-width: calc(var(--wrap) - (2 * var(--pad)));
	padding: 16px calc(var(--pad) - 6px);
	/* Éxito: el acento de marca. El tema no tiene un color propio de "correcto"
	   (tokens.css: «Correcto/completado no tiene color propio: es --accent-strong»). */
	border: 1px solid var(--accent-strong);
	border-left-width: 3px;
	border-radius: var(--radius);
	background: var(--accent-soft);
	color: var(--ink);
	font-size: 14px;
	line-height: 1.5;
}

.woocommerce-error li + li,
.woocommerce-info li + li,
.woocommerce-message li + li {
	margin-top: 8px;
}

.woocommerce-error a,
.woocommerce-info a,
.woocommerce-message a {
	color: var(--accent-strong);
	text-decoration: underline;
	text-underline-offset: .18em;
}

.woocommerce-error a:hover,
.woocommerce-info a:hover,
.woocommerce-message a:hover {
	color: var(--ink);
}

/* ==================================================================================
   BUSCADOR EN VIVO — las cuatro reglas que le faltaban al contrato
   ==================================================================================
   Viven aquí y no junto a su bloque en overlays.css porque el buscador en vivo solo existe con
   WooCommerce activo (inc/woocommerce/search.php es quien encola ueb-search.js y quien emite los
   chips). Sin tienda, la capa se queda con su formulario GET y estas reglas no hacen falta.
   Son movibles a overlays.css sin riesgo de cascada: `[attr]` sube la especificidad, así que
   ganan igual desde cualquiera de los dos archivos. */

/* `[hidden]` de la hoja del navegador es `display:none` con especificidad de ELEMENTO, así que
   pierde contra el `display:flex`/`display:grid` de la regla de clase. Es la misma trampa ya
   documentada para `.promo-form[hidden]` (overlays.css). Sin esto, la capa recién abierta deja
   20 px de aire donde irían los chips y la rejilla vacía se lleva su gap. */
.search-chips[hidden],
.search-grid[hidden] {
	display: none;
}

/* Refresco de una búsqueda que YA tiene resultados en pantalla: se atenúa en vez de vaciarse,
   para que no parpadee en cada tecla. El primer render sí muestra .search-loading. */
.search-grid[aria-busy="true"] {
	opacity: .55;
	transition: opacity var(--fast) ease;
}

/* El enlace «Ver los 23» hereda `a{color:inherit}` (base.css) y quedaba indistinguible del texto
   gris del recuento. No se usa `.link` (layout.css) porque ese estilo es mono/uppercase con
   icono — un tono de "acción de cabecera" que no pega con una frase de recuento normal. Y no se
   convierte `.search-meta` en flex para separarlos: es un <p>, y darle `display:flex`
   reventaría su propio `[hidden]` (la trampa de arriba). */
.search-meta a {
	margin-left: 10px;
	color: var(--accent-strong);
	text-decoration: underline;
	text-underline-offset: .2em;
}

.search-meta a:hover {
	color: var(--ink);
}

/* ==================================================================================
   FORMULARIO DE BÚSQUEDA CLÁSICO Y LISTA DE RESULTADOS
   ==================================================================================
   `.ueb-searchform` (searchform.php) y `.post-list` (search.php) no tenían ni una regla en todo
   el tema, y los dos se ven de verdad: get_search_form() lo llama el aviso «no se han encontrado
   productos» de WooCommerce, y .post-list sale en cuanto una búsqueda mezcla productos con
   páginas. El botón y el campo ya los estilan components.css y base.css; aquí solo falta
   colocarlos. */
.ueb-searchform {
	display: flex;
	gap: 10px;
	align-items: flex-end;
	flex-wrap: wrap;
	margin: 20px 0 8px;
}

.ueb-searchform .field {
	flex: 1;
	min-width: 220px;
}

.post-list {
	display: flex;
	flex-direction: column;
	gap: 24px;
}