/* ---------------------------------------------------------------------------
   Ajustes de Melcón Estudio sobre el diseño de Eloy.
   Aparte del suyo a propósito: así se ve de un vistazo qué es de quién y, si
   él rehace el diseño, se vuelve a enganchar este archivo y ya está.
   --------------------------------------------------------------------------- */

/* El bloque del equipo se salía 35 px por la derecha en móvil y movía la página
   entera de lado. Las cuatro fotos van en abanico sobre un escenario con
   márgenes negativos; la de la derecha va al 70% y girada 7°, y al girar una
   caja su envoltura se ensancha. Se recorta aquí, en el contenedor interior, y
   nunca en html/body: eso provoca el "scroll infinito" de Safari en iPhone.
   Y clip en vez de hidden para no cortar las sombras por abajo. */
/* CORREGIDO EL 29/08/2026, porque el recorte se comía las esquinas.
   Lo vio Eloy: "las esquinas salen cortadas... no salen con las puntas
   redondeadas". Tenía razón, y era culpa de este recorte.

   Medido en la web viva: en escritorio el escenario va de 766 a 1380 px, pero
   la primera foto empieza en 740 y la última acaba en 1404. Se salen ~25 px por
   cada lado y el recorte les cortaba el borde redondeado. No es que sobresalgan
   por error: al GIRAR una caja, su envoltura se ensancha en alto × seno del
   ángulo. Con 440 px de alto y 7°, son 27 px por lado. El diseño de Eloy los
   necesita.

   La solución es recortar MÁS LEJOS, no menos: la sección ocupa todo el ancho de
   la pantalla, así que ahí las fotos caben enteras y la página sigue sin poder
   desplazarse de lado. Sigue sin tocarse html/body, que es lo que provoca el
   "scroll infinito" de Safari en iPhone. */
.people-stage {
	overflow-x: visible;
	/* Sin esto, por debajo de 375 px el escenario deja de encoger: se queda
	   clavado en 371 px mientras la sección baja a 330 y a 290, y la última foto
	   se sale de la pantalla. Es el `min-width:auto` que traen de serie los
	   elementos de una caja flexible, que impide encoger por debajo del
	   contenido. Medido el 29/08/2026 a 390, 375, 360 y 320 px.
	   Importa porque 360 px es el ancho de móvil Android más común. */
	min-width: 0;
}
/* CORREGIDO OTRA VEZ EL 29/08/2026. El primer intento movió el recorte a la
   sección, y seguía cortando: la sección solo mide 1160 px de ancho (centrada,
   de 220 a 1380 en una pantalla de 1600) y la foto de Iñigo llega a 1404. Se
   comía 24 px de su borde derecho. Lo vio Angel mirando; no salió en mis
   medidas porque yo comprobaba si las fotos cabían en LA PANTALLA, y quien
   recorta no es la pantalla sino el contenedor que lleva el recorte.
   LECCIÓN: se mide contra la caja que recorta, no contra la ventana.

   Ahora se recorta en <main>, que sí ocupa todo el ancho: las fotos no se
   cortan nunca y la página sigue sin poder desplazarse de lado. Sigue sin
   tocarse html/body, que es lo que provoca el "scroll infinito" de Safari
   en iPhone. */
main { overflow-x: clip; }

/* En móvil no basta con mover el recorte: ahí las fotos se salen de la pantalla
   de verdad (medido a 390 px: la primera empezaba en -33 y la última acababa en
   426, con la pantalla acabando en 390). Así que se recoge el abanico y se
   estrechan un poco las tarjetas, lo justo para que quepan las cuatro CON sus
   esquinas. Se conserva el orden, la inclinación y el solape del diseño. */
/* Y esto es lo que impedía de verdad encoger. La sección del equipo es una
   rejilla y en móvil usa una columna `1fr`. Una columna `1fr` NO puede encoger
   por debajo del contenido que lleva dentro, así que se quedaba clavada en
   354,9 px aunque la pantalla bajara a 330 o a 290. `minmax(0, 1fr)` es la
   forma de decir "sí puedes encoger". Medido el 29/08/2026: sin esto, a 360 px
   la última foto se salía 5 px y a 320 px, 44. Y 360 px es el ancho de móvil
   Android más común.
   VA DENTRO DE SU MEDIA QUERY A PROPÓSITO: el diseño solo pasa a una columna a
   partir de 980 px. Escrito suelto, aplastaba también el escritorio, donde la
   sección tiene que ser de dos columnas (texto a la izquierda, fotos a la
   derecha). Pasó al probarlo el 29/08 y se vio midiendo. */
@media (max-width: 980px) {
	.team-section { grid-template-columns: minmax(0, 1fr); }
}

@media (min-width: 641px) and (max-width: 980px) {
	.person-card  { width: 29%; }
	.person-eloy  { left: 4%; }
	.person-new   { left: 25%; }
	.person-ruben { left: 46%; }
	.person-inigo { left: 67%; }
}

@media (max-width: 640px) {
	.person-card  { width: 31%; }
	.person-eloy  { left: 6%; }
	.person-new   { left: 24%; }
	.person-ruben { left: 42%; }
	.person-inigo { left: 60%; }
}

/* Aviso de cookies: si algún día se usa el propio del diseño en vez de un
   plugin, los botones de aceptar y rechazar tienen que ser idénticos en tamaño
   Y color (norma de Rubén, 27/08/2026, y lo que pide la AEPD). */
.cookie-actions .cookie-equal,
.cookie-actions .cookie-equal.cookie-accept {
  color: #fff; background: #1a73e8; border-color: #1a73e8;
}

/* Página de gracias tras reservar (no existía en el diseño original). */
.gm-gracias { padding: 38px 26px 46px; text-align: center; }
.gm-gracias .gm-tic { width: 62px; height: 62px; margin: 0 auto 18px; border-radius: 50%;
  background: #e8f0fe; color: #1a73e8; font-size: 30px; font-weight: 800; display: grid; place-items: center; }
.gm-gracias h1 { margin: 0 0 12px; font-size: 27px; line-height: 1.18; color: #0a0d13; }
.gm-gracias .gm-sub { margin: 0 auto 26px; max-width: 430px; color: #5b616e; font-size: 15px; line-height: 1.55; }
.gm-gracias ul { list-style: none; margin: 0 auto 30px; padding: 0; max-width: 430px; text-align: left; }
.gm-gracias ul li { display: flex; gap: 11px; padding: 11px 0; border-top: 1px solid #edf0f4;
  font-size: 14px; color: #1a2431; line-height: 1.45; }
.gm-gracias ul li:first-child { border-top: 0; }
.gm-gracias ul li span { color: #1a73e8; font-weight: 800; }
.gm-gracias .gm-volver { display: inline-block; background: #1a73e8; color: #fff; text-decoration: none;
  padding: 13px 26px; border-radius: 11px; font-weight: 700; font-size: 15px; }
@media (max-width: 560px) { .gm-gracias h1 { font-size: 22px; } .gm-gracias { padding: 30px 18px 36px; } }

/* Capa del vídeo de intro (el botón "Ver vídeo"). En el diseño original lo
   montaba React; aquí se pinta con JavaScript propio y necesita su estilo. */
.gm-capa-video { position: fixed; inset: 0; z-index: 9999; background: rgba(8,11,18,.86);
  display: grid; place-items: center; padding: 20px; }
.gm-capa-caja { position: relative; width: min(920px, 100%); }
.gm-capa-caja video { width: 100%; border-radius: 14px; display: block; background: #000; }
.gm-capa-cerrar { position: absolute; top: -46px; right: 0; width: 38px; height: 38px;
  border: 0; border-radius: 50%; background: #fff; color: #0a0d13; font-size: 22px;
  line-height: 1; cursor: pointer; }
@media (max-width: 560px) { .gm-capa-cerrar { top: -42px; } }

/* Para poder arrastrar las webs de ejemplo con el dedo sin que el móvil se
   quede con el gesto para desplazar la página. */
.interactive-landing-stage { touch-action: pan-y; }

/* El aviso de cookies del plugin es fijo y se comía parte del botón "Ver vídeo"
   (medido el 28/08/2026: lo tapaba en PC y en móvil). Mientras el aviso esté a
   la vista, el botón se coloca por encima de él; el JavaScript calcula cuánto. */
.floating-video-launch { bottom: var(--gm-flotante-abajo, 24px); }
.floating-video-conversion { bottom: var(--gm-flotante-abajo, 24px); }

/* El botón azul "Ajustes Cookies" que deja el plugin caía justo encima de la
   píldora de "Ver vídeo". En pantalla ancha hay sitio de sobra a la izquierda,
   que además es donde lo pone media internet. En móvil no cabe al lado, así que
   se quedan apilados: cookies abajo y el vídeo justo encima (el JavaScript
   calcula cuánto subirlo). */
#gdpr-cookie-consent-show-again { left: 24px !important; right: auto !important; }
@media (max-width: 760px) {
  #gdpr-cookie-consent-show-again { left: auto !important; right: 12px !important; }
}

/* Los puntitos del carrusel ahora se pueden pulsar: que se note. */
.search-selector button { cursor: pointer; }

/* El logo y el "Volver a la web" de la página del Código pasaron de <button> a
   enlace de verdad (antes no navegaban a ninguna parte). El CSS de Eloy los
   estilaba como botones sin fondo; a un enlace hay que quitarle además el
   subrayado para que se vea igual. */
.hard-home-link { text-decoration: none; }

/* Índice de las páginas legales: los subapartados van sangrados y algo más
   pequeños, para que se distingan de los bloques grandes sin romper el diseño. */
.gm-sub { padding-left: 14px; opacity: .82; }
.gm-sub span { opacity: .7; }

/* ───────────────────────────────────────────────────────────────────────────
   PANEL DE COOKIES: COLOCAR LOS BOTONES EN MÓVIL.        Melcón Estudio, 29/08/2026

   Lo avisó Sergio el 29/08 con una captura desde su iPhone. Reproducido a 390 px
   en Safari (WebKit) y en Chrome, con el mismo resultado en los dos: los tres
   botones se parten mal. "Rechazar todo" y "Aceptar todo" quedan apilados a la
   izquierda y "Guardar y aceptar" se va a la derecha partido en dos líneas.

   POR QUÉ PASA (verificado leyendo el CSS del plugin):
   el plugin trae reglas que colocan bien esos botones en pantallas estrechas,
   pero están escritas para un panel llamado `#gdpr-ccpa-gdprmodal` y el que usa
   esta web se llama `#gdpr-gdprmodal`. Como no coinciden, esas reglas no se
   aplican nunca y mandan los estilos que el plugin escribe dentro de la propia
   etiqueta (flex-wrap:wrap), que es lo que produce el desorden.

   Se arregla desde aquí y NO tocando el plugin: así una actualización suya no
   se lo lleva por delante, y se deshace borrando este bloque.
   Hace falta !important porque lo que se corrige son estilos escritos dentro de
   la etiqueta, que mandan sobre cualquier hoja.

   OJO, REGLA QUE NO SE TOCA: "Rechazar todo" y "Aceptar todo" quedan del mismo
   tamaño y del mismo color. Rechazar tiene que ser igual de fácil que aceptar;
   si se hace más pequeño o más discreto, el consentimiento deja de ser válido.
   ─────────────────────────────────────────────────────────────────────────── */
@media (max-width: 600px) {
	#gdpr-gdprmodal .gdprmodal-footer .gdpr-footer-buttons,
	#gdpr-gdprmodal .gdprmodal-footer .gdpr-footer-left {
		flex-direction: column !important;
		align-items: stretch !important;
		flex-wrap: nowrap !important;
		width: 100% !important;
		gap: 8px !important;
	}
	#gdpr-gdprmodal .gdprmodal-footer .gdpr-footer-buttons button {
		width: 100% !important;
		margin: 0 !important;
	}
}

/* ───────────────────────────────────────────────────────────────────────────
   RED DE SEGURIDAD: QUE EL PANEL DE COOKIES NO SE DESPARRAME POR LA HOME.
                                                        Melcón Estudio, 29/08/2026

   Lo destapó Sergio el 29/08: bajando por la home se encontró el panel de
   preferencias escrito como texto suelto al final. No se equivocó de sitio.

   POR QUÉ PASA (reproducido el mismo día bloqueando el archivo):
   el panel está SIEMPRE dentro del HTML de todas las páginas, y lo que lo
   mantiene oculto es el CSS del plugin. Ese archivo se llama
   `gdpr-cookie-consent-frontend.css`, y los bloqueadores de anuncios del móvil
   filtran por nombres así. Cuando un visitante lo tiene bloqueado, el panel
   deja de estar oculto y añade 1.382 px de texto crudo al final de la página:
   la home pasa de 10.512 a 11.894 px. Medido, no supuesto.

   Desde el 31/08 toda la publicidad va a esa home, así que esto le puede pasar
   a una parte de las visitas pagadas.

   POR QUÉ ESTA REGLA ES SEGURA:
   el plugin abre el panel escribiendo `style="display:block"` en la propia
   etiqueta, y eso manda sobre cualquier hoja de estilos. Así que esta regla
   solo actúa cuando el panel está cerrado. Verificado el 29/08 en la copia:
   cerrado lleva `class="gdprmodal gdprfade"` y sin estilo propio; abierto lleva
   `gdprshow` y `display:block` escrito dentro.

   VA EN NUESTRO ARCHIVO A PROPÓSITO: `ajustes.css` no tiene "cookie" ni "gdpr"
   en el nombre, así que ningún bloqueador lo filtra. Si esta regla viviera en
   el plugin, se caería junto con el resto.

   LA BARRA DE COOKIES NO SE TOCA: esa tiene que verse sí o sí, aunque salga
   sin estilos, porque es donde el visitante da o niega el permiso. Ocultarla
   sería dejarle sin poder decidir.
   ─────────────────────────────────────────────────────────────────────────── */
.gdprmodal {
	display: none;
}

/* ───────────────────────────────────────────────────────────────────────────
   LOS DOS BOTONES FLOTANTES, COLOCADOS.          Melcón Estudio, 29/08/2026

   Encargo de Eloy: *"a ver si pudieses alinear los dos botones... o sea que
   estén a la misma altura... y no tapar lo del codigo gastromaps"* y, sobre
   todo, *"lo que mas me importa es el movil siempre... que en el movil jamas
   interfiera la ux del usuario"*.

   Medido antes de tocar nada:
     · PC:     "Ver vídeo" a 24 px del fondo, "Ajustes Cookies" a 10. Descuadrados.
     · Móvil:  "Ver vídeo" a 66 px y "Ajustes Cookies" a 10, uno sobre otro, y el
               de vídeo tapando el texto de la certificación a media pantalla.
   ─────────────────────────────────────────────────────────────────────────── */

/* 1 · El mismo suelo para los dos, para que se lean como una pareja. */
#gdpr-cookie-consent-show-again {
	bottom: 24px !important;
	left: 24px !important;
	right: auto !important;
}

/* 2 · En móvil, el de cookies pasa a la izquierda.
   Esto no es solo estética: nuestro JavaScript sube el botón de vídeo ÚNICAMENTE
   cuando algo le pisa la columna ("si está a la izquierda, no estorba", en
   gastromaps.js). Con el de cookies a la derecha, el de vídeo se subía a 66 px y
   tapaba contenido a media pantalla. Moviéndolo, los dos caben en la misma fila
   abajo y el de vídeo baja solo a su sitio. Cero JavaScript nuevo. */
@media (max-width: 760px) {
	#gdpr-cookie-consent-show-again {
		left: 15px !important;
		right: auto !important;
	}
}

/* 3 · Que el pie no quede debajo de los botones.
   En móvil ya reservaba 100 px; en escritorio no reservaba nada, y por eso el
   botón de cookies se comía "El Código GASTROMAPS". */
@media (min-width: 761px) {
	footer { padding-bottom: 100px; }
}

/* ───────────────────────────────────────────────────────────────────────────
   QUE "RECHAZAR TODO" QUEPA EN UNA SOLA LÍNEA EN EL MÓVIL.
                                                        Melcón Estudio, 31/08/2026

   Lo pidió Eloy el 29/08 con una captura de su iPhone: "esto sí que lo de
   RECHAZAR TODO que quepa en la misma línea".

   QUÉ PASABA (medido, no a ojo): los dos botones del aviso tienen el mismo
   ancho, pero "Rechazar todo" es un texto más largo y se partía en dos líneas.
   Resultado: 64 px de alto frente a 45 px del de aceptar. Además de quedar
   descuadrado, hacía que el de rechazar pareciera "otra cosa". Pasaba entre
   360 y 390 px de ancho, que es la franja de casi todos los móviles.

   ARREGLO: una sola línea, prohibir el corte. Nada más hace falta: el texto
   cabe de sobra en el ancho que ya tenían. NO se toca el tamaño de la letra
   ni el relleno, así que los dos botones siguen idénticos y igual de legibles.

   (Se probó también bajar el relleno de 26 a 12 px y se quitó porque NO hacía
   nada: ese valor lo escribe el plugin dentro de la propia etiqueta con
   !important y gana siempre. Comprobado mirando el estilo aplicado, no el
   escrito.)

   Comprobado en 9 anchos (320 a 600 px) con el motor de Safari y el de Chrome,
   y después en la web ya desplegada: los dos botones idénticos, en una línea
   y sin texto cortado.

   OJO, LA REGLA DE SIEMPRE: rechazar tiene que ser igual de fácil que aceptar.
   Si alguna vez hace falta más sitio, se reduce la letra de LOS DOS a la vez,
   nunca solo la del de rechazar.
   ─────────────────────────────────────────────────────────────────────────── */
@media (max-width: 600px) {
	#gdpr-cookie-consent-bar .gdpr_action_button {
		white-space: nowrap !important;
	}
}

/* ---------------------------------------------------------------------------
   LA CABECERA Y EL PRIMER GOLPE DE VISTA   (08/09/2026)

   Tres cosas que pidió Eloy en un vídeo de 35 s recorriendo la web:
     1. Fuera el botón de la cabecera — "hay demasiados botones por todos lados".
     2. El logo, centrado.
     3. El botón del hero, más arriba, "que entre dentro del pantallazo".

   El tercero se midió antes de tocarlo, y el problema era mayor de lo que él
   veía: el botón acababa en 807 px. En su MacBook (850 de alto útil) entra por
   43 px; en un portátil de 1440x800 se corta por 7. De ahí que él lo viera
   justo y avisara de que "a lo mejor en el tuyo aparece de otra forma".
   --------------------------------------------------------------------------- */

/* 1 y 2 · La cabecera se queda solo con el logo, centrado. */
.site-header { justify-content: center; }
.site-header > .button { display: none; }

/* 3 · Menos aire arriba para que la llamada a la acción entre en la primera
       pantalla. Solo en escritorio: en móvil el hero ya se apila y ahí el aire
       hace falta. */
@media (min-width: 1024px) {
  .hero { padding-top: 34px; padding-bottom: 54px; min-height: 560px; }
}