/* Theme Name: Vinculare Description: Tema a medida para Vinculare, gabinete de psicología y psiquiatría. Landing informativa con animaciones GSAP/ScrollTrigger. Version: 1.0.0 License: GNU General Public License v2 or later License URI: https://www.gnu.org/licenses/gpl-2.0.html Text Domain: vinculare */ /* Reset básico */ *, *::before, *::after { box-sizing: border-box; } html { scroll-behavior: smooth; /* Bug real, reportado en móvil (iPhone): al llegar al final de las 3 secciones "telón" de Inicio (ver animateFullscreenSnap en animations.js) y seguir haciendo scroll hacia el footer, la página "rebotaba" de vuelta a la última sección en vez de seguir. Causa: el gesto de rebote elástico nativo del navegador al llegar al final real de la página (el "estirón" que hace iOS/Android al tocar el límite) cruza de nuevo hacia arriba el umbral de ScrollTrigger de esa última sección, disparando su "onEnterBack" como si el usuario hubiera dado marcha atrás de verdad. overscroll-behavior-y:none desactiva ese rebote elástico del navegador en los bordes del documento — sin él, no hay ningún cruce falso que reactivar. No afecta al scroll normal del resto de la página, solo a ese gesto de "tirar de más" en los extremos. */ overscroll-behavior-y: none; } /* Barra de scroll a medida, en toda la web (la de la página y la de cualquier contenedor con su propio scroll interno, como el texto del diálogo de "Leer más" en Conócenos): finita, rectangular (sin esquinas redondeadas ni sombra), siempre fondo niebla y barrita oliva — colores fijos, no dependen de en qué página/zona esté (se probó a seguir el tinte de cada página con una variable CSS, pero al ser un elemento tan fino la diferencia era imperceptible y no compensaba la complejidad). Firefox usa scrollbar-width/scrollbar-color (heredable, por eso va en *); Chrome/Edge/Safari usan los pseudo-elementos ::-webkit-scrollbar-*, que hay que declarar en cada elemento (de ahí el selector * en vez de solo html/body). Desde Chrome 121, si un elemento tiene scrollbar-width/scrollbar-color con un valor no inicial, Chrome descarta TODAS sus reglas ::-webkit-scrollbar-* (ancho, sin flechas, colores) y usa su propio "thin" nativo de ancho fijo — por eso scrollbar-width/scrollbar-color va dentro de @supports not selector(::-webkit-scrollbar): así solo lo ve Firefox (que no soporta ::-webkit-scrollbar), y Chrome/Edge/ Safari siguen aplicando el estilo fino y sin flechas de más abajo. */ :root { /* Ancho real de la barra en Chrome/Edge/Safari — variable en vez de un valor repetido, para que el hueco de separación de .team-bio-dialog__layout (ver más abajo) mida siempre exactamente lo mismo que la barra, se toque un valor u otro. Firefox no tiene forma de igualarse a esto: scrollbar-width solo acepta thin/auto/none, sin control en px. */ --scrollbar-width: 3.75px; } @supports not selector(::-webkit-scrollbar) { * { scrollbar-width: thin; scrollbar-color: var(--color-oliva) var(--color-niebla); } } *::-webkit-scrollbar { width: var(--scrollbar-width); height: var(--scrollbar-width); } *::-webkit-scrollbar-track { background: var(--color-niebla); margin: 0; border: none; border-radius: 0; box-shadow: none; } *::-webkit-scrollbar-thumb { background-color: var(--color-oliva); margin: 0; padding: 0; border: none; border-radius: 0; box-shadow: none; } *::-webkit-scrollbar-corner { background: var(--color-niebla); } /* Sin flechas en los extremos — hay que anular cada estado por separado (:single-button, :double-button, :start, :end, :increment, :decrement); con solo *::-webkit-scrollbar-button Chrome sigue dibujando la flecha en algunos casos. */ *::-webkit-scrollbar-button, *::-webkit-scrollbar-button:single-button, *::-webkit-scrollbar-button:double-button, *::-webkit-scrollbar-button:start, *::-webkit-scrollbar-button:end, *::-webkit-scrollbar-button:increment, *::-webkit-scrollbar-button:decrement { display: none !important; width: 0 !important; height: 0 !important; background: transparent !important; } @media (prefers-reduced-motion: reduce) { html { scroll-behavior: auto; } *, *::before, *::after { animation-duration: 0.01ms !important; animation-iteration-count: 1 !important; transition-duration: 0.01ms !important; scroll-behavior: auto !important; } } /* En Inicio, el color de fondo del body se anima con GSAP/ScrollTrigger según la zona por la que se va scrolleando (ver animations.js) — sin transición CSS aquí para no competir con esa animación. */ body { margin: 0; font-family: var(--font-texto); color: var(--color-berenjena); background-color: var(--color-niebla); line-height: 1.5; } /* Fondo limpio por página (ver header.php): toda la página, no una franja aparte. .site-header hereda este mismo color (background-color:inherit), así que no hace falta tocarlo aquí. bg-tint-lavanda/bg-tint-pistacho ya no las asigna ninguna página (Servicios y las 15 hijas de Qué tratamos comparten ahora este mismo tinte melocotón, ver header.php) — --color-lavanda-tint/ --color-pistacho-tint se dejan definidas en tokens.css por si hace falta variedad de tinte en el futuro, pero estas dos reglas de fondo ya no tenían ningún sitio que las usara. */ body.bg-tint-melocoton { background-color: var(--color-melocoton-tint); } /* Conócenos, a petición expresa: melocotón "casi sin aclarar" en vez del tinte pálido de arriba — el mínimo aclarado posible que deje el texto del menú superior (berenjena, sin --zone-text en esta página) legible. El melocotón de marca SIN diluir ya da 5.2:1 contra berenjena (por encima del 4.5:1 mínimo AA), y diluirlo con blanco solo AUMENTA ese contraste (nunca lo empeora) — así que el propio color de marca, tal cual, ya es el punto de "mínimo aclarado que sigue siendo legible": no hace falta aclarar nada más. */ body.bg-tint-melocoton-fuerte { background-color: var(--color-melocoton); } /* Contacto, a petición expresa: mismo criterio que bg-tint-melocoton-fuerte de arriba (color de marca SIN diluir) pero en pistacho — pistacho contra berenjena da ~6:1, por encima del 4.5:1 mínimo AA, así que tampoco hace falta aclarar nada. */ body.bg-tint-pistacho-fuerte { background-color: var(--color-pistacho); } /* Qué tratamos (solo la página índice, ver header.php) — a petición expresa, para probar: fondo oliva SIN diluir, la única página fuera de Inicio con un tinte OSCURO en vez de uno claro, así que (a diferencia de las reglas de arriba) aquí SÍ hace falta voltear el color de texto del body entero — el resto de páginas dejan el default de (berenjena, ver arriba) sin tocarlo porque sus tintes son todos claros. niebla-clara, no blanco puro ni niebla base: mismo criterio que --color-niebla-clara en tokens.css (el niebla base falla AA de texto normal sobre oliva). */ body.bg-tint-oliva { background-color: var(--color-oliva); color: var(--color-niebla-clara); } /* El menú hereda el fondo (background-color:inherit en .site-header, ver más abajo) pero NO el color de texto — .site-header fija el suyo propio (var(--zone-text, var(--color-berenjena)), pensado para Inicio) y aquí, fuera de Inicio, --zone-text nunca está definida, así que sin este override el menú se quedaría en el berenjena de respaldo, ilegible sobre oliva. */ body.bg-tint-oliva .site-header { color: var(--color-niebla-clara); } /* .page-header__intro fija su propio berenjena (ver más abajo, pensado para el resto de páginas, todas con fondo claro) — aquí necesita el mismo volteo que el body. */ body.bg-tint-oliva .page-header__intro { color: var(--color-niebla-clara); } /* Contorno de foco: el berenjena por defecto (ver el bloque grande más abajo) da solo 2.36:1 contra oliva, por debajo del 3:1 mínimo AA para componentes de interfaz (WCAG 2.2, "non-text contrast") — apenas se vería. Mismo criterio que ya usa Inicio para su propia zona oscura, ver [data-bg-zone="berenjena"] a:focus-visible más abajo. */ body.bg-tint-oliva a:focus-visible, body.bg-tint-oliva button:focus-visible { outline-color: var(--color-niebla-clara); } /* Servicios — a petición expresa, para probar: "todo el fondo de la página fuese en lavanda con todo el texto en blanco". Mismo patrón que body.bg-tint-oliva justo arriba (fondo OSCURO sin diluir, texto niebla-clara), pero lavanda es el MÁS CLARO de los tres colores de marca lo bastante oscuros para texto claro encima (berenjena/oliva/ lavanda, ver brandbook-vinculare) — pasa AA con niebla-clara encima (5.02:1, la misma cifra que ya usa Inicio para su propia zona oscura en .section--about-cta) pero NO con berenjena (solo 2.16:1): a diferencia de oliva, aquí el respaldo de var(--zone-text, ...) que usan varios componentes de la web (pensado para Inicio, con berenjena de vuelta) NO sirve de nada — hay que voltear cada componente que dé por hecho un fondo claro, uno a uno, ver los bloques de más abajo. Esta clase sigue siendo el respaldo sin JS/con prefers-reduced-motion (página lavanda de principio a fin, como aquí) pero, a petición expresa, YA NO es el punto de partida real de la página con JS activo: animateBgFade() en animations.js arranca la cadena en niebla/ berenjena/pistacho (cabecera + Psicología/Psiquiatría) y funde a este mismo lavanda/niebla-clara justo al llegar a "Áreas de atención" (ver data-bg-fade="lavanda" ahí, page-servicios.php) — el primer eslabón de la cadena que antes solo cubría FAQ/Tarifas. `color` aquí y en .site-header/.page-header__intro/el contorno de foco de más abajo pasan a leer var(--zone-text, ...) en vez del niebla-clara fijo de siempre, para que esa animación (que solo toca --zone-text, nunca estas reglas de clase) los pueda ir mezclando; el respaldo (niebla-clara) dentro del var() es exactamente el valor fijo de antes, así que sin JS el resultado no cambia. */ body.bg-tint-lavanda { background-color: var(--color-lavanda); color: var(--zone-text, var(--color-niebla-clara)); } /* Corrige un parpadeo real reportado al cargar/recargar Servicios (o entrar desde el menú): "por un momento se ve lavanda antes de ponerse el fondo niebla correcto". Causa — ya documentada arriba, "YA NO es el punto de partida real de la página con JS activo": esta clase pinta lavanda de inmediato (CSS puro, en el primer frame), pero con JS activo el punto de partida REAL a scroll 0 es niebla (animateBgFade() en animations.js no llega a correr y sobreescribir background-color hasta que el script se carga/ejecuta, unos frames más tarde) — ese hueco entre "pinta lavanda" y "JS corrige a niebla" es el parpadeo. @media (prefers-reduced-motion: no-preference) en vez de arreglarlo por JS (adelantar el cálculo no evitaría el hueco, solo lo acortaría): así el niebla correcto se pinta ya en el primer frame, sin esperar a ningún script, y SOLO para el mismo caso en el que animateBgFade() va a correr de verdad — con prefers-reduced-motion activado (donde animateBgFade() ni se ejecuta, ver el bloque grande al principio de animations.js) el body se queda en el lavanda de la regla base de arriba, tal como se pensó como respaldo. */ @media (prefers-reduced-motion: no-preference) { body.bg-tint-lavanda { background-color: var(--color-niebla); } } body.bg-tint-lavanda .site-header { color: var(--zone-text, var(--color-niebla-clara)); } body.bg-tint-lavanda .page-header__intro { color: var(--zone-text, var(--color-niebla-clara)); } /* Contorno de foco: el berenjena por defecto da solo 2.16:1 contra lavanda, por debajo del 3:1 mínimo AA para componentes de interfaz — igual que ya le pasaba a oliva (2.36:1), apenas se vería. var(--zone-text, ...), no el niebla-clara fijo de antes — mismo motivo que las reglas de arriba: en la zona niebla/berenjena inicial (antes de "Áreas de atención") el contorno berenjena por defecto SÍ pasa AA de sobra contra niebla, así que aquí también tiene que poder seguir a --zone-text en vez de quedarse en blanco fijo. */ body.bg-tint-lavanda a:focus-visible, body.bg-tint-lavanda button:focus-visible, body.bg-tint-lavanda summary:focus-visible { outline-color: var(--zone-text, var(--color-niebla-clara)); } /* Mismo parpadeo/mismo arreglo que el fondo del body más arriba — estos tres --zone-text tenían el respaldo (niebla-clara, pensado para lavanda de fondo) sin actualizar: con el fondo ya corregido a niebla en el primer frame (arriba), un texto/contorno CLARO ahí encima habría sido casi invisible hasta que animateBgFade() fijara --zone-text de verdad — el mismo hueco de antes, solo que de texto en vez de fondo. berenjena, no niebla-clara: es el color de texto correcto sobre niebla (zona CLARA, ver el porqué en animateSectionBackgrounds()/lightZones en animations.js). Con prefers-reduced-motion (fondo lavanda de la regla base, sin este override) el respaldo se queda en niebla-clara, correcto ahí. */ @media (prefers-reduced-motion: no-preference) { body.bg-tint-lavanda .site-header, body.bg-tint-lavanda .page-header__intro { color: var(--zone-text, var(--color-berenjena)); } body.bg-tint-lavanda a:focus-visible, body.bg-tint-lavanda button:focus-visible, body.bg-tint-lavanda summary:focus-visible { outline-color: var(--zone-text, var(--color-berenjena)); } } /* .btn--secondary es un botón de contorno en el resto del tema (fondo transparente, borde/texto en berenjena) — aquí, a petición expresa, pasa a ser un relleno sólido blanco (niebla-clara) con el texto en lavanda, a juego con el propio fondo de la página. border-color iva al mismo blanco que el fondo (no currentColor/lavanda): así no dibuja un contorno lavanda alrededor del botón, y el grosor de 2px ya reservado por .btn (ver más abajo) no cambia el tamaño del botón al pasar de esta regla al hover. El hover/foco se repite aquí, EXACTAMENTE igual que el de .btn--secondary:hover sin escopar (mismo relleno berenjena sólido + texto niebla) — a petición expresa, "que el hover lo siga haciendo igual". No basta con dejar que el hover sin escopar de más abajo "gane" solo: body.bg-tint-lavanda .btn--secondary tiene más especificidad (dos clases + el tipo "body") que .btn--secondary:hover (dos clases), así que sin repetirlo aquí el relleno blanco de reposo se quedaría fijo también en hover, tapando el cambio a berenjena. */ body.bg-tint-lavanda .btn--secondary { background-color: var(--color-niebla-clara); color: var(--color-lavanda); border-color: var(--color-niebla-clara); } body.bg-tint-lavanda .btn--secondary:hover, body.bg-tint-lavanda .btn--secondary:focus-visible { background-color: var(--color-berenjena); /* Blanco, no niebla — a petición expresa, "todos los botones con fondo berenjena, texto en blanco" (ver --color-blanco en tokens.css). */ color: var(--color-blanco); border-color: transparent; } /* .btn--primary ("Pide tu primera cita", en Tarifas) — mismo cambio y mismo motivo que .btn--secondary justo arriba: relleno sólido blanco con texto lavanda en reposo, a petición expresa, con el hover/foco (berenjena sólido + texto niebla) repetido aquí para que no deje de invertir al pasar el ratón — .btn--primary no fija border-color propio (se queda transparente heredado de .btn), así que aquí no hace falta tocarlo. */ body.bg-tint-lavanda .btn--primary { background-color: var(--color-niebla-clara); color: var(--color-lavanda); } body.bg-tint-lavanda .btn--primary:hover, body.bg-tint-lavanda .btn--primary:focus-visible { background-color: var(--color-berenjena); color: var(--color-blanco); } /* .service-card__answer ul YA NO necesita el volteo a niebla-clara que llevaba aquí: ese texto vivía antes directamente sobre el lavanda oscuro de la página (el desplegable in-place); ahora vive dentro de la "ventanita" flotante (.service-bio-dialog, ver más abajo), una tarjeta melocotón-tint clara igual que las de Conócenos — el lavanda fijo de base en .service-card__answer ul ya pasa AA ahí tal cual, igual que en el resto de escenarios donde se usa ese mismo texto. */ /* FAQ: línea divisoria, icono +/− e texto de la respuesta (.faq-item__answer fija lavanda fijo — invisible sobre el propio lavanda del fondo de esta página sin este volteo). El enlace dentro de una respuesta (.faq-item__answer a, la política de cancelación) fija berenjena — aquí pasa a niebla-clara también; sigue distinguiéndose del resto del párrafo por su propio font-weight:600 y subrayado, no solo por color, así que no hace falta un tercer color solo para el enlace. */ /* var(--zone-text, ...), NO el niebla-clara fijo que llevaba antes — a petición expresa ("que las líneas separadoras de FAQ también hagan la transición de color junto con el texto"): sin esto, estas líneas se quedaban fijas en niebla-clara durante todo el scrub de FAQ→Tarifas (--zone-text pasando de niebla-clara a berenjena, ver data-zone-text="berenjena" en .section--pricing, page-servicios.php) mientras el resto de texto sin color propio (los h3 de cada pregunta, ver .faq-item__question h3 más abajo, sin color propio, heredan var(--zone-text, ...) del body) sí iba mezclándose en tiempo real — un desajuste visible entre línea y texto según se acercaba Tarifas. Mismo mecanismo ya en uso en body.bg-tint-lavanda .pricing-list__item, más abajo. */ body.bg-tint-lavanda .faq-item, body.bg-tint-lavanda .faq-item:first-child { border-color: color-mix(in srgb, var(--zone-text, var(--color-niebla-clara)) 25%, transparent); } /* var(--zone-text, ...), NO el niebla-clara fijo que llevaba antes — mismo motivo/mismo mecanismo que .faq-item más arriba ("que las líneas separadoras de FAQ también hagan la transición de color junto con el texto"): sin esto el icono +/− se quedaba fijo en niebla-clara (blanco) durante todo el scrub FAQ→Tarifas mientras el resto (línea divisoria, texto de la pregunta) sí iba mezclándose. */ body.bg-tint-lavanda .faq-item__icon::before, body.bg-tint-lavanda .faq-item__icon::after { background-color: var(--zone-text, var(--color-niebla-clara)); } /* var(--zone-text, ...), NO el niebla-clara fijo que llevaba antes — a petición expresa ("que las respuestas desplegadas de FAQ también hagan la transición de color junto con el resto de los textos ahí"): mismo mecanismo/mismo motivo que .faq-item y .faq-item__icon aquí arriba (la pregunta/línea/icono ya se mezclaban con --zone-text durante el scrub FAQ→Tarifas; la respuesta desplegada se quedaba fija en niebla-clara, desajustada del resto en cuanto se abría una pregunta cerca de Tarifas). */ body.bg-tint-lavanda .faq-item__answer, body.bg-tint-lavanda .faq-item__answer a { color: var(--zone-text, var(--color-niebla-clara)); } /* Tarifas: .pricing-list__duration, .pricing-note p, .pricing-list__price y .pricing-group__title fijan cada uno su propio color base (más abajo), así que sin este volteo se quedarían con ese color fijo pensado para un fondo claro. var(--zone-text, ...), NO el niebla-clara fijo que llevaba antes — a petición expresa ("que el texto de Tarifas también pase a berenjena"): con --zone-text ya puesta a "berenjena" en este tramo (ver data-zone-text="berenjena" en .section--pricing, page-servicios.php), estas cuatro excepciones tienen que seguir ese mismo cambio en vez de quedarse coladas en niebla-clara — ahí un texto casi blanco sobre el pistacho tan claro de este tramo apenas se leería. El respaldo (niebla-clara) es el mismo de siempre para prefers-reduced-motion/sin JS (--zone-text sin definir en ese escenario, toda la página lavanda de principio a fin, donde berenjena SÍ fallaría el contraste — 2.16:1). .pricing-list__title no lleva color propio (hereda del body), así que ya se voltea solo sin tocarlo aquí. */ body.bg-tint-lavanda .pricing-list__duration, body.bg-tint-lavanda .pricing-note p, body.bg-tint-lavanda .pricing-list__price, body.bg-tint-lavanda .pricing-group__title { color: var(--zone-text, var(--color-niebla-clara)); } /* Mismo volteo que las cuatro excepciones de arriba y por el mismo motivo — a petición expresa ("las líneas divisorias de Tarifas también en berenjena"): color-mix con niebla-clara se quedaba casi invisible sobre el pistacho claro de este tramo (una línea casi blanca sobre un fondo casi blanco), igual que le habría pasado al texto de arriba sin este mismo cambio. */ body.bg-tint-lavanda .pricing-list__item { border-color: color-mix(in srgb, var(--zone-text, var(--color-niebla-clara)) 25%, transparent); } h1, h2, h3, h4, h5, h6 { font-family: var(--font-titulos); /* A petición expresa: EB Garamond solo en su versión Medium (500) en toda la web — sin esto, los navegadores ponen negrita por defecto en los títulos (700), y Google Fonts ahora solo carga el peso 500 (ver functions.php), así que sin este font-weight explícito el navegador tendría que "inventarse" una negrita sintética en vez de usar una versión real de la fuente. */ font-weight: 500; line-height: 1.2; margin: 0 0 0.5em; } img { max-width: 100%; height: auto; display: block; } a { color: inherit; } /* Accesibilidad: enlace "saltar al contenido" */ .skip-link { position: absolute; top: -100%; left: 0; background: var(--color-berenjena); color: #fff; padding: 0.75em 1.25em; z-index: 1000; transition: top 0.2s ease; } .skip-link:focus { top: 0; } /* Foco visible en todos los elementos interactivos (WCAG 2.2 AA). Berenjena, no melocotón: melocotón da 1.74:1 contra niebla y 2.2:1 contra blanco, ambos por debajo del 3:1 mínimo para componentes de interfaz — el foco por defecto apenas se veía en Servicios, Conócenos, Blog, Qué tratamos y el formulario de contacto (todo lo que no tiene una anulación más específica para zonas oscuras). */ a:focus-visible, button:focus-visible, input:focus-visible, textarea:focus-visible, select:focus-visible, summary:focus-visible { outline: 3px solid var(--color-berenjena); outline-offset: 2px; } /* .section--about-cta (única zona oscura que queda en Inicio, ver style.css) ya fija su propio color de texto — este contorno de foco en blanco puro es lo único que sigue haciendo falta aparte: el contorno por defecto es melocotón, con poco contraste sobre fondo oscuro; blanco puro vale igual aquí (es un anillo fino, no texto, así que basta con 3:1, no con el 4.5:1 que pediría texto). */ [data-bg-zone="berenjena"] a:focus-visible { outline-color: #fff; } /* Cursor personalizado (solo dispositivos con ratón, ver animations.js) */ .cursor-dot, .cursor-ring { position: fixed; top: 0; left: 0; pointer-events: none; opacity: 0; z-index: 9999; } .cursor-dot { width: 8px; height: 8px; border-radius: 50%; background-color: var(--color-melocoton); } .cursor-ring { /* Trazo dibujado a mano (ver header.php), no un círculo geométrico, para que encaje con el estilo de las ilustraciones del hero. */ width: 44px; height: 44px; fill: none; stroke: var(--color-melocoton); stroke-width: 4; overflow: visible; transition: scale 0.25s ease, stroke 0.25s ease; } .cursor-ring.is-active { scale: 1.5; stroke: var(--color-berenjena); } html.has-custom-cursor, html.has-custom-cursor a, html.has-custom-cursor button { cursor: none; } html.has-custom-cursor .cursor-dot, html.has-custom-cursor .cursor-ring { opacity: 1; } /* Con un abierto (ver animations.js), el navegador lo pinta en el "top layer", por encima de CUALQUIER z-index del documento normal — el punto/aro del cursor personalizado (por altos que tengan el z-index) quedan tapados detrás, así que no se ve ningún cursor en absoluto mientras el diálogo está abierto. Aquí se recupera el cursor nativo del sistema mientras dure — pero SOLO en html.dialog-open a secas, ya NO en "html.dialog-open a"/"html. dialog-open button" (quitados): con el cursor personalizado desactivado (ver el "cursor nativo del sistema en toda la web" en animations.js), esas dos líneas de más ya no tenían nada que restaurar y en su lugar causaban un bug real, reportado con capturas — forzaban cursor:auto en CUALQUIER botón/enlace dentro de un diálogo abierto (más específico que ".btn { cursor: pointer }", ver ahí), y el navegador resuelve ese "auto" ahí dentro como cursor de texto en vez de la manita, aunque el propio enlace/botón siguiera funcionando con normalidad al pulsarlo. */ /* Con la tarjeta flotante abierta, la página de fondo no debe poder hacer scroll ni enseñar su propia barra: overflow:hidden en bloquea el scroll del documento entero mientras dure — el /su tarjeta interior siguen haciendo su propio scroll con toda normalidad, al vivir en el "top layer", ajenos al overflow de . Misma clase, puesta/quitada por DOS sitios distintos — animations.js (el diálogo de biografías de Conócenos) y hoja-a-mesa.js (las tarjetas de las ilustraciones que caen en Inicio) — a petición expresa, "no tiene sentido" que se pudiera seguir haciendo scroll por detrás de NINGÚN del sitio: showModal() por sí solo no lo impide, solo bloquea foco/clic. */ html.dialog-open { overflow: hidden; } html.dialog-open { cursor: auto; } html.dialog-open .cursor-dot, html.dialog-open .cursor-ring { opacity: 0; } /* Sobre la cabecera y el hero (fondo oliva) el cursor cambia a blanco para seguir siendo visible. */ html.cursor-on-accent .cursor-dot { background-color: #fff; } html.cursor-on-accent .cursor-ring { stroke: #fff; } html.cursor-on-accent .cursor-ring.is-active { stroke: var(--color-niebla); } /* Cabecera del sitio: siempre pegada arriba (sticky) y con el mismo fondo que la zona visible en ese momento (background-color:inherit hereda el color en vivo que anima animateSectionBackgrounds() sobre — en páginas sin ese sistema se queda en el niebla por defecto). El color de texto sigue la variable --zone-text que actualiza ese mismo script: niebla-clara en zona oscura (oliva/lavanda), berenjena en el resto. El logo hereda este mismo color (fill: currentColor en su SVG), así que cambia con el menú. SIN transition en "color" a propósito (se probó, ver el porqué largo en animateSectionBackgrounds(), animations.js): --zone-text ya se actualiza fotograma a fotograma desde JS con su propio fundido continuo ligado al scroll real, así que una transición CSS encima competía con esa animación en vez de sumarse a ella (cada nuevo valor por fotograma reiniciaba su propia transición de 0.25s, una carrera de metas móviles que se sentía con retraso/deriva respecto al fondo en vez de sincronizada con él). */ .site-header { display: flex; align-items: center; justify-content: space-between; gap: 1rem; min-height: var(--header-height); padding: 1rem clamp(1rem, 4vw, 3rem); background-color: inherit; color: var(--zone-text, var(--color-berenjena)); /* -webkit-sticky antes de "sticky" — Safari (sobre todo iOS) necesitaba históricamente este prefijo para no tratar la propiedad entera como inválida y caer a position:static (la cabecera dejaría de pegarse arriba en scroll, se iría con el resto de la página). Las versiones actuales ya no lo necesitan, pero declararlo de más no hace nada en un Safari moderno (que ya entiende "sticky" sin prefijo) — cuesta una línea, cubre cualquier versión más vieja que quede en uso real. */ position: -webkit-sticky; position: sticky; top: 0; z-index: 100; /* translateZ(0) — a petición expresa, tras reportarse "al hacer scroll en móvil aparece un hueco encima del menú" CON la sesión de WordPress iniciada (barra de administración visible). Comprobado con un script de prueba (Playwright, simulando la barra de admin real de WordPress): el CÁLCULO en sí es correcto — top:46px dejaba esta cabecera pegada al borde inferior de la barra de admin en TODAS las posiciones de scroll probadas, hueco:0px siempre. Encaja con un tipo de bug conocido de Safari/Chrome en móvil, no con un error de este CSS: la barra de direcciones del propio navegador se esconde al hacer scroll (para dar más pantalla), y tanto ella como cualquier elemento position:fixed/sticky de la página (aquí, la PROPIA barra de administración de WordPress — position:fixed, ver #wpadminbar, fuera del control de este tema) pueden quedarse un instante "rezagados" repintándose mientras dura esa animación, dejando ver un hueco pasajero justo donde debería estar la barra — no un fallo de posición real y permanente, sino un instante de descoordinación del propio navegador. translateZ(0) (con backface-visibility de refuerzo) es la mitigación estándar documentada para esto: obliga a esta cabecera a su propia capa de composición en la GPU de antemano, en vez de que el navegador decida crearla tarde, a mitad de scroll — puede notarse mejor o peor según el dispositivo/navegador exacto, al ser un comportamiento del propio sistema, no de este código. position:absolute (no fixed) en .main-nav, más abajo: importante que siga siendo así — un transform aquí convierte a ESTA cabecera en el "containing block" de cualquier descendiente position:fixed (rompería el panel de menú a pantalla completa si volviera a ser fixed, ver su propio comentario largo). */ transform: translateZ(0); backface-visibility: hidden; } /* Con sesión iniciada, la barra de admin de WordPress empuja la página hacia abajo al cargar (32px, 46px en móvil), pero eso no mueve el "top: 0" del sticky — al hacer scroll, la cabecera se pega al borde real de la pantalla, debajo de esa barra (que sí se queda fija ahí siempre), y parece que "sube" y pierde el hueco de arriba. Un visitante sin sesión nunca ve esto: solo afecta a quien gestiona el sitio. .admin-bar es la clase que WordPress añade solo al cuando la barra está visible. */ body.admin-bar .site-header { top: 32px; } @media (max-width: 782px) { /* Mismo punto de corte que usa WordPress para la barra de admin en móvil (más alta: 46px en vez de 32px). */ body.admin-bar .site-header { top: 46px; } } /* Mientras .section--about-cta está detrás de la cabecera (ver el mismo listener de scroll+rAF en animations.js, reutilizado también para .section--about más abajo): sin fondo propio — sus dos flores decorativas (.about-cta-flor, ver style.css) asoman por encima del propio borde superior de la sección, y con la cabecera opaca encima la de arriba a la derecha se veía cortada en seco justo debajo del menú (mismo motivo, y mismo reporte, que llevó a .site-header--over-arena más abajo: "una barrita" tapando el SVG). Transparente, se ve la flor entera. Este es el fondo "por defecto" mientras la sección entera está detrás de la cabecera — ver site-header--over-about-cta-link más abajo para el "fondito" que se superpone SOLO cerca de la frase "Conocer nuestro equipo". */ .site-header.site-header--over-about-cta { background-color: transparent; } /* "Fondito" del menú SOLO mientras la frase-enlace "Conocer nuestro equipo" (.about-cta-link-wrap--left, la primera de las dos, la que está pegada arriba dentro de .about-cta-links — ver flex-direction:column ahí — así que es la que se acerca a la cabecera primero al hacer scroll hacia el footer) está a punto de quedar detrás del menú — a petición expresa ("que aparezca solo cuando el espacio del menú va a entrar en contacto con ESE texto", no durante toda la sección): esa frase es del mismo color casi blanco que el texto del menú sobre el mismo fondo berenjena, sin nada que los separase visualmente. Clase e icono de seguimiento aparte (site-header--over-about-cta-link, ver el nuevo tracked{} en animations.js) en vez de reutilizar site-header--over-about-cta de arriba: esa otra sigue haciendo falta transparente durante TODA la sección para el color del texto del menú (ver --zone-text más abajo) y para las flores — estrechar esa regla a solo el tramo de la primera frase habría dejado el resto de la sección (y la segunda frase, "Descubrir cómo podemos ayudarte") sin ese ajuste de color. "Cristal" translúcido + desenfocado (mismo tratamiento que body.bg-tint-lavanda .site-header en Servicios, ver más abajo), no un fondo sólido: por si la flor de arriba-derecha llegase a rozar el borde del menú en pantallas más bajas, se leería como un desenfoque suave por detrás, no como un corte en seco. var(--live- bg, ...) sigue el mismo fundido continuo de animateSectionBackgrounds() que ya pinta el body (ver el porqué de --zone-text más abajo): con un color fijo aquí, el fondo del menú se habría desincronizado del real igual que ya pasaba antes con el texto. Va DESPUÉS de site-header--over-about-cta en el archivo a propósito: las dos clases conviven a la vez sobre
mientras dura este tramo (misma especificidad, dos clases cada una), así que el orden en la hoja de estilos decide qué "background-color" gana. */ .site-header.site-header--over-about-cta-link { background-color: color-mix(in srgb, var(--live-bg, var(--color-berenjena)) 88%, transparent); } @supports ( backdrop-filter: blur(1px) ) or ( -webkit-backdrop-filter: blur(1px) ) { .site-header.site-header--over-about-cta-link { -webkit-backdrop-filter: blur(14px); backdrop-filter: blur(14px); } } /* Panel del menú hamburguesa en móvil: mismo motivo que body.bg-tint-melocoton-fuerte/-oliva/etc. .main-nav más abajo (ver ese comentario grande) — hereda background-color:inherit, así que sin esto se quedaría con el mismo cristal translúcido+desenfocado de la cabecera fina, dejando ver el contenido de la página moviéndose por debajo de los enlaces (ilegible). Sólido, no color-mix con --live-bg: un panel de navegación real prioriza la legibilidad sobre seguir el efecto cristal, igual que las otras páginas "cristal". */ body .site-header.site-header--over-about-cta-link .main-nav { background-color: var(--color-berenjena); } /* about-cta depende de --zone-text: aquí el berenjena de fondo no es un color fijo, lo produce enteramente el fundido continuo de animateSectionBackgrounds() mientras se hace scroll. Con un niebla-clara fijo aquí (como se probó antes), el texto del menú saltaba de golpe al valor final en cuanto la sección empezaba a asomar tras la cabecera —el propio cruce de rect.top/headerHeight que activa esta clase—, un instante discreto que casi nunca coincidía con lo mezclado que estuviera YA el fondo real en ese momento exacto: a veces el texto se veía clarear de golpe antes de que el fondo hubiera oscurecido lo bastante, otras veces se quedaba con un tono a medio camino un rato de más — reportado como que el menú "cambia de color" fuera de sincronía con el fondo. var(--zone-text, ...) sigue actualizándose en el MISMO fotograma que ya pinta document.body (nunca puede desincronizarse EN EL TIEMPO de él), pero ya NO es literalmente el mismo número que el fondo interpolado — bug real reportado después: mezclar --zone-text en RGB entre berenjena y niebla-clara a la vez que el fondo mezcla pistacho→berenjena cruza, a mitad de camino, por dos tonos intermedios casi igual de oscuros (fondo aclarándose desde berenjena, texto oscureciéndose hacia él desde el otro lado) — contraste medido de ~1.5:1 justo ahí, el menú "se quedaba en berenjena e ilegible" al entrar en esta sección. Ahora animateSectionBackgrounds() elige en cada fotograma el extremo (berenjena o niebla-clara) con más contraste WCAG contra el fondo real de ESE fotograma, así que --zone-text salta entre los dos extremos en vez de mezclarse — el "transition: color" de .site- header (más arriba) es lo que convierte ese salto discreto en un fundido corto y suave, sincronizado con el punto exacto en el que el fondo real deja de dar buen contraste con uno y empieza a darlo con el otro. El respaldo (berenjena) cubre prefers-reduced-motion/ sin JS: sin animateSectionBackgrounds(), about-cta se queda con el niebla claro por defecto del body (ver el hueco documentado ahí), así que ahí hace falta texto OSCURO, no claro. La regla de color en sí (.site-header.site-header--over-about-cta) vive MÁS ABAJO en este archivo, después de -hero/-arena/-hero-cta — a propósito, no por descuido: bug real reportado ("el menú del footer... el texto sigue oscuro al llegar a las flores"), confirmado con la consola del navegador — .site-header llegaba a la última sección (Inicio) con DOS clases de zona puestas a la vez, site-header--over-about-cta Y site-header--over-hero-cta (la sección justo anterior, pistacho/clara), porque el propio rect de .section--hero-cta seguía dando "todavía solapa" (rect.bottom > 0) en el navegador real del usuario aun con about-cta ya llenando toda la pantalla. Con las cuatro reglas de zona a la misma especificidad (dos clases cada una), el ORDEN en la hoja de estilos decide cuál "color" gana cuando dos coinciden a la vez — y -hero-cta (más abajo en el archivo antes de este cambio) fijaba berenjena FIJO, ganándole al var(--zone-text, ...) correcto de about-cta. Resultado: menú ilegible (berenjena sobre el propio berenjena de fondo) justo en la sección que más lo necesita. Declarando about-cta DESPUÉS de las otras tres zonas de Inicio, su color (el único de los cuatro que seguía el contraste real en vivo) gana cualquier empate futuro, pase lo que pase con el resto de zonas. */ /* Mientras el hero de Inicio está detrás de la cabecera (ver el mismo listener de scroll+rAF de arriba) — sin fondo propio, a petición expresa, para que .hero__bg-illustration (bailando.svg, ver el comentario grande de .hero más abajo) se vea también por debajo del menú en vez de quedar cortada en seco por su fondo opaco justo donde asoma por arriba (mismo motivo, y mismo reporte, que llevó a .site-header--over-arena un poco más abajo). Berenjena, no niebla- clara: niebla es una zona CLARA, mismo motivo que en la arena. */ .site-header.site-header--over-hero { background-color: transparent; color: var(--color-berenjena); } .site-header.site-header--over-hero a:focus-visible { outline-color: var(--color-berenjena); } /* Mientras la arena física de ilustraciones (.section--about) está detrás de la cabecera (ver el mismo IntersectionObserver de arriba): sin fondo propio, no por un motivo de color (niebla es la misma zona clara antes y después, ver el fundido continuo) sino porque las 5 ilustraciones "caen" desde fuera de la vista, por encima de su propia caja (ver initArena en hoja-a-mesa.js), atravesando de verdad la franja de la cabecera mientras "llueven" hacia su sitio. Con la cabecera opaca encima, cada una se veía cortada en seco justo en su borde inferior — reportado como "aparece una barrita y no se ven los SVG ahí". Transparente, se ve la caída completa, sin ese corte. Berenjena, no niebla-clara: niebla es una zona CLARA, así que le hace falta texto oscuro encima. */ .site-header.site-header--over-arena { background-color: transparent; color: var(--color-berenjena); } .site-header.site-header--over-arena a:focus-visible { outline-color: var(--color-berenjena); } /* .section--hero-cta, de vuelta en este sistema (ver el porqué largo en animations.js, justo encima de donde se añade esta clase al array "tracked"): en móvil, la hoja--left asoma bastante por ARRIBA del párrafo (ver .hero-outro-hoja--left en su propio breakpoint más abajo) — con la cabecera opaca encima se cortaba en seco justo en su borde inferior según la sección se metía debajo. var(--zone-text, ...), YA NO berenjena fijo (a diferencia de .site-header--over-hero/-arena, que sí se quedan fijas — ver el porqué de cada una arriba): "pistacho es una zona CLARA" solo es cierto en el PROPIO punto de anclaje de hero-cta, no durante todo su scroll — animateSectionBackgrounds() funde el fondo real EN CONTINUO desde ese pistacho hacia el berenjena de about-cta a lo LARGO DE TODO EL ALTO de esta sección (los dos son "stops" consecutivos, ver stops[] en animations.js), así que el fondo real ya está bastante oscurecido bastante ANTES de llegar siquiera a about-cta. Con berenjena fijo aquí (versión anterior), el menú se quedaba en texto oscuro sobre un fondo que llevaba un buen tramo oscureciéndose de verdad — y, reportado aparte ("el menú no hace la transición al mismo ritmo que el fondo"): en cuanto about-cta entraba en juego y esta regla dejaba de ganar el empate (ver el comentario grande junto a site-header--over-about-cta más abajo), --zone-text aparecía de golpe ya con el valor al que hubiera llegado mientras tanto SIN QUE EL MENÚ LO HUBIERA MOSTRADO NUNCA — un salto instantáneo en vez del fundido gradual que sí se veía en el propio fondo. Con --zone-text aquí también, el menú sigue el MISMO contraste en vivo, todo el tiempo, sin ninguna costura entre esta zona y la siguiente: solo hay UNA fuente de color de texto para las dos, así que no puede haber salto entre ellas. El respaldo (berenjena) cubre el mismo escenario sin JS/con prefers-reduced-motion que el resto de usos de --zone-text: sin animateSectionBackgrounds(), esta sección se queda con el fondo niebla claro por defecto del body (nunca llega a pintarse pistacho de verdad), así que ahí también hace falta texto oscuro. */ .site-header.site-header--over-hero-cta { background-color: transparent; color: var(--zone-text, var(--color-berenjena)); } .site-header.site-header--over-hero-cta a:focus-visible { outline-color: var(--zone-text, var(--color-berenjena)); } /* Declarada AQUÍ, después de -hero/-arena/-hero-cta (ver el comentario grande junto a --zone-text más arriba en este archivo, junto a .site-header.site-header--over-about-cta-link, para el porqué exacto): con las cuatro reglas de zona a la misma especificidad, el orden en la hoja de estilos decide cuál gana cuando el navegador marca dos clases de zona a la vez (bug real confirmado por consola: -over-hero-cta seguía puesta, junto a esta, ya con about-cta llenando toda la pantalla). -over-hero-cta ya usa var(--zone-text, ...) también (ver su propio comentario más arriba, mismo motivo), así que hoy por hoy las dos reglas coinciden siempre que ambas clases conviven a la vez — este orden ya no cambia el resultado visual, pero se deja así (about-cta la última) como red de seguridad ante cualquier futura zona de Inicio que vuelva a fijar un color propio sin pasar por --zone-text. */ .site-header.site-header--over-about-cta { color: var(--zone-text, var(--color-berenjena)); } .site-header.site-header--over-about-cta a:focus-visible { outline-color: var(--zone-text, var(--color-berenjena)); } /* Conócenos, a petición expresa: el estampado de hojas de fondo (.conocenos-hojas-fondo, dentro de #main) tiene que leerse como el MISMO fondo que el resto de la página también por debajo del menú, no cortado en seco al llegar a la cabecera. Con background-color normal (heredado, sólido) la cabecera sticky tapaba las hojas en cuanto pasaban por debajo al hacer scroll. background-color TRANSLÚCIDO (rgba del propio --color-melocoton) + backdrop-filter:blur(), no transparent del todo (versión anterior) — a petición expresa, tras reportarse que al hacer scroll el menú quedaba encima de las fichas del equipo (y del diálogo de bio de cada una, ver .team-bio-dialog más abajo) "solapado y feo, no se lee bien": con transparencia total, cualquier cosa que pasara por detrás de la cabecera —no solo las hojas decorativas, también fotos y tarjetas con su propio color— se veía a través DEL TODO, así que el contraste del texto del menú dejaba de estar garantizado en cuanto había una ficha (en vez del fondo liso de siempre) justo debajo. 88% de opacidad del propio melocotón: ya casi opaco (mismo contraste que el fondo sólido de siempre para el texto berenjena del menú, sea lo que sea que haya detrás), pero con ese 12% restante + el desenfoque de fondo, las hojas (y cualquier otra cosa) se siguen intuyendo suavemente A TRAVÉS en vez de cortarse en seco — ni el corte duro que se quería evitar en la versión original, ni la transparencia total que rompía la legibilidad sobre las fichas. @supports: navegadores sin backdrop-filter (raros hoy, pero los hay) se quedan con el translúcido sin desenfocar — sigue siendo igual de legible, solo que lo que se intuye detrás se ve algo menos "esmerilado" y más "rayado". */ body.bg-tint-melocoton-fuerte .site-header { background-color: rgb(243 153 93 / 88%); } /* Contacto — a diferencia de bg-tint-melocoton-fuerte justo arriba, SIN tinte de color: a petición expresa, "que el svg decorativo de fondo (grupo.svg) se vea también por debajo del menú, que el fondo del menú no lo tape". Un color-mix() al 88% (como el resto de páginas "cristal") lo tapaba casi del todo — transparent del todo dejando solo el desenfoque (ver @supports más abajo) para que el texto del menú se siga leyendo bien cuando pasa algo por detrás, sin ocultar la ilustración. */ body.bg-tint-pistacho-fuerte .site-header { background-color: transparent; } /* Blog y "Qué tratamos" (bg-tint-oliva) — a petición expresa, "que el menú adquiera el mismo efecto [cristal con vaho] que tiene el de Conócenos": mismo mecanismo que body.bg-tint-melocoton-fuerte justo arriba (fondo translúcido del propio color de la página + desenfoque detrás, ver el porqué largo ahí), aplicado ahora también aquí. color-mix(), no un rgb() calculado a mano como el bloque de arriba (escrito antes de que este patrón entrara en el resto del archivo, ver .faq-item más abajo para el mismo color-mix ya en uso): mismo resultado sin tener que convertir cada hex de marca a decimal. Esta página tiene un fondo FIJO (a diferencia de Servicios, ver el bloque siguiente), así que basta con el color de marca directo, sin nada dinámico. */ body.bg-tint-melocoton .site-header { background-color: color-mix(in srgb, var(--color-melocoton-tint) 88%, transparent); } body.bg-tint-oliva .site-header { background-color: color-mix(in srgb, var(--color-oliva) 88%, transparent); } /* Servicios (bg-tint-lavanda) — mismo efecto, pero el fondo de esta página YA NO es un color fijo: arranca en niebla y se funde a lavanda/berenjena/oliva según el scroll (ver animateBgFade() en animations.js). Un translúcido fijo de un solo color se habría quedado "enganchado" en el tono equivocado en cuanto el fondo real cambiara de color por debajo del menú. --live-bg (fijada por esa misma función, en paralelo a backgroundColor, en cada fotograma) lleva siempre el mismo color exacto que el body en ese instante, así que el cristal del menú sigue al fondo real en todo momento del fundido. Respaldo (--color-lavanda) para prefers-reduced-motion/sin JS, donde --live-bg nunca llega a definirse: mismo color fijo que ya pinta body.bg-tint-lavanda en ese escenario. */ body.bg-tint-lavanda .site-header { background-color: color-mix(in srgb, var(--live-bg, var(--color-lavanda)) 88%, transparent); } @supports ( backdrop-filter: blur(1px) ) or ( -webkit-backdrop-filter: blur(1px) ) { body.bg-tint-melocoton-fuerte .site-header, body.bg-tint-pistacho-fuerte .site-header, body.bg-tint-melocoton .site-header, body.bg-tint-oliva .site-header, body.bg-tint-lavanda .site-header { -webkit-backdrop-filter: blur(14px); backdrop-filter: blur(14px); } } /* Bug real, reportado en móvil: .main-nav (el panel del menú hamburguesa, ver @media max-width:64rem más abajo) hereda background-color:inherit — en estas 5 páginas "cristal" de arriba, eso significa que el panel del menú abierto se queda con el MISMO 88% translúcido + desenfoque que la cabecera compacta, dejando ver el contenido de la página moviéndose por debajo de los enlaces de navegación (ilegible, "roto"). El cristal tiene sentido en la cabecera fina (deja intuir la ilustración/tarjeta de detrás), pero no en un panel de navegación real: aquí prioriza la legibilidad (mismo criterio que el resto del sitio con el contraste WCAG) sobre seguir el efecto — mismo color de cada página, pero sólido, sin mezclar con transparencia ni desenfoque. No hace falta media query: en escritorio .main-nav es display:contents (ver más abajo), así que un background-color aquí no llega a pintar nada. */ body.bg-tint-melocoton-fuerte .main-nav { background-color: var(--color-melocoton); } body.bg-tint-pistacho-fuerte .main-nav { background-color: var(--color-pistacho); } body.bg-tint-melocoton .main-nav { background-color: var(--color-melocoton-tint); } body.bg-tint-oliva .main-nav { background-color: var(--color-oliva); } body.bg-tint-lavanda .main-nav { background-color: var(--live-bg, var(--color-lavanda)); } /* Mismo parpadeo que el ya corregido en body.bg-tint-lavanda (ver arriba), reportado otra vez pero "ahora solo en la barra de menú de arriba": la cabecera y el panel de menú móvil de Servicios usan var(--live-bg, ...) con el mismo respaldo --color-lavanda de antes de arreglar el fondo del body — --live-bg no existe hasta que animateBgFade() lo fija en su primer fotograma, así que hasta entonces la cabecera se pintaba con ESE respaldo (lavanda) en vez del niebla real de partida, el mismo hueco de antes de corregirlo ahí solo en el body. Mismo arreglo, mismo criterio de cuándo aplicarlo (solo si animateBgFade() va a correr de verdad). */ @media (prefers-reduced-motion: no-preference) { body.bg-tint-lavanda .site-header { background-color: color-mix(in srgb, var(--live-bg, var(--color-niebla)) 88%, transparent); } body.bg-tint-lavanda .main-nav { background-color: var(--live-bg, var(--color-niebla)); } } /* Bug real, reportado en móvil: al llegar al pie de página, la cabecera sticky (en las páginas "cristal" de arriba) sigue translúcida+desenfocada — deja ver borroso el logo grande del footer justo detrás, un choque de color feo contra el pie (siempre berenjena sólido) y encima ilegible. site-header--over-footer (ver el nuevo seguimiento de .site-footer en animations.js, mismo mecanismo que site-header--over-hero/-arena/-about-cta, antes solo en Inicio) fuerza el mismo berenjena sólido que el propio footer mientras dure el solape — se lee como una continuación del pie, no como un cristal roto encima. "body" en el selector, no solo ".site-header.site-header--over-footer": sube la especificidad por encima de las reglas body.bg-tint-* .site-header de arriba (mismas 2 clases que estas, así que sin este empate a favor el orden en el archivo decidiría el ganador en vez de la intención). */ body .site-header.site-header--over-footer { background-color: var(--color-berenjena); color: var(--color-niebla-clara); } body .site-header.site-header--over-footer a:focus-visible { outline-color: var(--color-niebla-clara); } body .site-header.site-header--over-footer .main-nav { background-color: var(--color-berenjena); } @supports ( backdrop-filter: blur(1px) ) or ( -webkit-backdrop-filter: blur(1px) ) { body .site-header.site-header--over-footer { -webkit-backdrop-filter: none; backdrop-filter: none; } } .site-header a:focus-visible { /* El contorno de foco por defecto es melocotón, con poco contraste tanto sobre fondo oscuro como sobre niebla. */ outline-color: var(--zone-text, var(--color-berenjena)); } .site-header__logo { display: inline-flex; align-items: center; gap: 0.5rem; /* position:relative + z-index — mismo motivo que .nav-toggle (ver su comentario): se queda visible por encima del panel de menú a pantalla completa en móvil (ver .main-nav más abajo), en vez de desaparecer detrás en cuanto se abre. En escritorio no hace nada (.main-nav nunca cubre nada ahí), así que no hace falta media query. */ position: relative; z-index: 2; color: inherit; text-decoration: none; font-family: var(--font-titulos); font-size: 1.25rem; } .site-header__logo svg { width: auto; /* Antes 3rem: hacía que el logo pesara mucho más que el resto del menú. A esta altura queda a la escala de un elemento más del menú, no de un bloque aparte. */ height: 1.75rem; } .site-header__logo svg path { fill: currentColor; } /* .main-nav y su