/*
 * header.css — topbar de utilidad + barra de navegación.
 * Medidas exactas extraídas de _dev/diseno/Diseño sitio G&O.pdf (página `inicio`), vector puro
 * (get_drawings) — no estimadas. Detalle completo en _dev/registro-decisiones.md, 2026-08-14.
 *
 * Hallazgo de estructura: la topbar es full-bleed (su rect de fondo mide el ancho completo de la
 * página). La barra oscura del nav NO es full-bleed: su rect mide el mismo ancho que el
 * contenedor de contenido (`.gyo-container`).
 *
 * Corrección de arquitectura, 2026-08-14 (verificada con Chrome headless contra el render del
 * PDF): el nav NO flota sobre fondo blanco de página. La imagen de fondo del hero arranca
 * inmediatamente después de la topbar (y=55) y se extiende detrás de TODA la banda de navegación,
 * incluida la franja de 36px y los márgenes a los costados de la barra oscura — se ve, no es
 * blanco. Esto resuelve a favor de "es la misma nav con la foto detrás" la pregunta que
 * `plan-segmentacion.md` §2.1 dejaba abierta entre `inicio` y las páginas interiores: las 7
 * páginas comparten el mismo tratamiento (nav superpuesta a una foto), no hay dos variantes.
 * Por eso `.gyo-nav` es `position:absolute` dentro de un contenedor `.gyo-hero` con imagen de
 * fondo — no un bloque de flujo normal con fondo propio.
 */

.gyo-topbar {
  background-color: var(--color-beige);
  height: var(--gyo-topbar-height-1);
}

.gyo-topbar__inner {
  display: flex;
  align-items: center;
  height: 100%;
}

.gyo-topbar__item {
  display: flex;
  align-items: center;
  gap: var(--gyo-topbar-gap-icono-texto-1);
  font-size: var(--gyo-font-size-topbar);
  color: var(--color-negro-texto);
  white-space: nowrap;
}

.gyo-topbar__item + .gyo-topbar__item {
  margin-left: 19px; /* medido: gap entre fin de "contacto@gyoestudio.cl" e ícono de ubicación */
}

.gyo-topbar__item svg {
  width: 18px;
  height: 18px;
  flex-shrink: 0;
}

.gyo-topbar__instagram {
  margin-left: auto;
  display: flex;
  color: var(--color-negro-texto);
}

.gyo-topbar__instagram svg {
  width: 22px;
  height: 22px;
}

/* Fase 3 (2026-08-18): la fila de la topbar (email + dirección + instagram, sin wrap) mide
   ~677px de mínimo — ya rompía a 375px (hallazgo 8 de la auditoría 2026-08-18, deferido a esta
   fase). `flex-wrap` en vez de ocultar contenido: los 3 ítems pasan a su propia línea si no
   entran, sin perder información. `height:auto` porque con más de 1 línea el alto fijo
   (--gyo-topbar-height-1, 55px) ya no alcanza. */
@media (max-width: 767.98px) {
  .gyo-topbar {
    height: auto;
  }

  .gyo-topbar__inner {
    flex-wrap: wrap;
    row-gap: var(--gyo-space-2);
    padding-block: var(--gyo-space-2);
  }

  .gyo-topbar__instagram {
    margin-left: 0;
  }
}

/* .gyo-hero: contenedor genérico para cualquier sección con foto de fondo + nav superpuesta
   (hero-inicio, y también hero-pagina-interior en las 6 páginas interiores — mismo mecanismo,
   ver nota de arquitectura arriba). El alto real lo define cada variante de página.
   Bug real, encontrado 2026-08-18 (Fase 3, Parte B): `overflow:hidden` recortaba el dropdown
   mobile (`.gyo-nav__menu`) a partir del 4º link — el dropdown es `position:absolute` y no
   empuja el alto del hero (los elementos posicionados no participan del flujo), así que en
   cuanto el menú desplegado necesitaba más alto del que el hero ya tenía, `overflow:hidden` lo
   recortaba en el borde inferior del hero. No era un problema de altura del propio menú (que ya
   no tenía ningún `height`/`max-height` fijo) — era el ancestro cortando por su cuenta. Se separa
   en `overflow-x`/`overflow-y`: el recorte horizontal se mantiene (protege contra cualquier
   sub-píxel de la foto de fondo), el vertical se libera para que el dropdown pueda extenderse
   más allá del hero sin cortarse. */
.gyo-hero {
  position: relative;
  overflow-x: hidden;
  overflow-y: visible;
}

.gyo-hero__bg {
  position: absolute;
  inset: 0;
  width: 100%;
  height: 100%;
  object-fit: cover;
  z-index: 0;
}

/* Oscurece la foto para que el texto beige/blanco tenga contraste — visible en el render pero sin
   opacidad exacta todavía medida (no hay forma de leerla del vector, hay que despejarla por
   comparación de color foto-sin-overlay vs. foto-con-overlay en el render; queda para el pase de
   diff-cero de esta página). Valor de trabajo provisional. */
.gyo-hero__overlay {
  position: absolute;
  inset: 0;
  background-color: rgba(29, 29, 29, 0.55); /* PROVISIONAL */
  z-index: 1;
}

/* Barra oscura del nav: mismo ancho que la COLUMNA de contenido de .gyo-container (max-width
   menos sus propios márgenes laterales), no el ancho del contenedor en sí. Corrección
   2026-08-17: la primera versión le daba a la barra su propio `max-width` igual al del
   contenedor completo (1920px) en vez de vivir DENTRO de `.gyo-container` — a 1924px de ancho
   el error era casi invisible (~4px), pero a 2560px la barra habría quedado pegada a los bordes
   del `max-width` en vez de traer los mismos 94px de margen que el resto del sitio. Encontrado
   al diffear contra el render del PDF por columna (x=10): la barra oscura tapaba la foto en una
   franja donde el PDF muestra foto. Ahora `.gyo-nav__bar` vive dentro de un `.gyo-container`
   (ver index.html), así que solo necesita el padding interno propio (38px), el margen de 94px ya
   lo pone el contenedor. */
.gyo-nav {
  position: absolute;
  top: var(--gyo-header-gap-topbar-nav-6); /* 36px medidos entre el borde de la foto y la barra */
  left: 0;
  right: 0;
  z-index: 2;
}

.gyo-nav__bar {
  background-color: var(--color-negro-fondos);
  height: var(--gyo-header-height-9);
  width: 100%; /* llena la columna de contenido de .gyo-container (que ya trae los 94px de
    margen) — no un max-width propio, ver nota de corrección arriba */
  padding-inline: var(--gyo-nav-padding-inline-6); /* solo el padding interno propio (38px) */
}

.gyo-nav__inner {
  display: flex;
  align-items: center;
  justify-content: space-between;
  height: 100%;
}

/* Bug real, encontrado 2026-08-18 al verificar el rango 992–1440px (Fase 3, Parte B): sin
   `flex-shrink:0`, el default de flexbox (`flex-shrink:1` + `min-width:auto`) deja que el logo —
   el único de los 3 grupos del nav sin un "piso" de contenido real (`.gyo-nav__links`/
   `.gyo-boton-outline--nav` no se comprimen porque su texto no puede achicarse más allá de su
   ancho mínimo) — se comprima hasta ~0px cuando el nav no entra completo, mientras el navegador
   sigue *pintando* la imagen a su tamaño real (distorsionada/fuera de su caja). El resultado: el
   link "Inicio" se posiciona como si el logo no ocupara espacio y termina superpuesto a la imagen
   que sigue ahí — el bug real detrás de "INICIO pisa el logo". `flex-shrink:0` en los 3 grupos
   (ver `.gyo-nav__links`/`.gyo-boton-outline--nav` más abajo): ninguno se comprime nunca, así que
   el punto de quiebre a hamburguesa (ver media query, corregido de 992 a donde el contenido real
   entra completo) es el único mecanismo que evita el desborde. */
.gyo-nav__logo {
  flex-shrink: 0;
}

.gyo-nav__logo img {
  height: 158px; /* medido: bbox del logo 176.4×158px dentro de la barra de 202px, 22px de margen arriba/abajo */
  width: auto;
}

/* Bug real, encontrado 2026-08-19 al ajustar el gap del dropdown mobile: estas 2 reglas base
   (fila horizontal, ancho de referencia) tienen que declararse ANTES del `@media
   (max-width:1329.98px)` de más abajo. Antes vivían después (mismo selector, misma
   especificidad) — con igual especificidad, la regla que aparece más tarde en el archivo gana
   SIEMPRE, sin importar si el media query matchea o no, así que la versión "base" de acá abajo
   pisaba silenciosamente el `gap`/`padding-bottom` que el media query intentaba fijar para mobile
   en TODOS los anchos, incluido el de referencia. Encontrado por medición (`getComputedStyle` daba
   el mismo valor en 1923px y en 768px, tenía que dar distinto), no a ojo — ver
   _dev/registro-decisiones.md 2026-08-19. */
.gyo-nav__links {
  display: flex;
  align-items: center;
  gap: var(--gyo-nav-link-gap-7);
  flex-shrink: 0; /* ver nota del bug real en .gyo-nav__logo — este grupo ya no se comprimía por
    tener un piso de contenido propio (el texto no envuelve), pero se deja explícito para que los
    3 grupos del nav compartan el mismo criterio y no dependan de un efecto colateral */
}

.gyo-nav__links a {
  font-size: var(--gyo-font-size-nav);
  color: var(--color-beige); /* texto claro sobre fondo oscuro = beige, no blanco (P3) */
  text-transform: uppercase;
  position: relative;
  padding-bottom: 19px; /* espacio hasta el guion indicador, ver .gyo-nav__links li.activa */
  transition: color 0.2s ease;
}

/* Fase 3 (2026-08-18): menú mobile (dropdown desde el ícono hamburguesa), ver
   _dev/registro-decisiones.md para el criterio completo. `.gyo-nav__menu` envuelve los links +
   el botón Contacto — a `lg` (992px) y por encima es invisible como caja (`display:contents`):
   sus hijos participan directo del flex de `.gyo-nav__inner`, cero cambio de layout respecto a
   antes de agregar este wrapper. Por debajo de `lg` pasa a ser el panel del dropdown. */
.gyo-nav__menu {
  display: contents;
}

.gyo-nav__toggle {
  display: none;
  align-items: center;
  justify-content: center;
  width: 44px;
  height: 44px;
  padding: 0;
  border: none;
  background: transparent;
  color: var(--color-beige);
  cursor: pointer;
}

.gyo-nav__toggle svg {
  width: 28px;
  height: 28px;
}

.gyo-nav__toggle .gyo-nav__icono-cerrar {
  display: none;
}

.gyo-nav__toggle[aria-expanded="true"] .gyo-nav__icono-abrir {
  display: none;
}

.gyo-nav__toggle[aria-expanded="true"] .gyo-nav__icono-cerrar {
  display: block;
}

/* Bug real, encontrado 2026-08-18 (Fase 3, Parte B): a 992px (el breakpoint `lg` de Bootstrap,
   usado acá sin verificar que el CONTENIDO del nav entrara ahí) el nav horizontal no tenía
   espacio real para logo + 5 links + botón CONTACTO — con `flex-shrink:0` ya puesto (ver arriba,
   antes ninguno se comprimía "bien": el logo colapsaba a ~0px mientras seguía pintándose a su
   tamaño real, superponiéndose a "Inicio"), medido con CDP el ancho natural del contenido
   (logo 176px + links 721px + botón 169px = 1066px) más el padding de la barra (76px) y el
   margen del container (188px, fijo en 94px/lado desde `lg`) da un mínimo real de ~1330px de
   viewport para que todo entre sin desbordar la barra — no 992px. Se sube el punto de quiebre a
   hamburguesa a donde el contenido realmente entra completo (medido, no el default de Bootstrap
   sin verificar), con ~23px de margen sobre el cruce exacto medido (~1307px). No se eligió
   comprimir el nav (gap más chico, logo más chico) en vez de subir el breakpoint: el menú
   hamburguesa ya es un componente completo y probado (Parte A), cubrir un rango más ancho con él
   no es una experiencia peor — comprimir el nav horizontal hubiera significado inventar tamaños
   nuevos sin ninguna medida del PDF que los respalde. */
@media (max-width: 1329.98px) {
  .gyo-nav__toggle {
    display: flex;
  }

  .gyo-nav__menu {
    display: none;
    position: absolute;
    top: 100%;
    left: 0;
    right: 0;
    flex-direction: column;
    align-items: flex-start;
    gap: var(--gyo-space-4);
    background-color: var(--color-negro-fondos);
    padding: var(--gyo-space-4) var(--gyo-nav-padding-inline-6) var(--gyo-space-5);
  }

  /* La barra oscura mide `--gyo-header-height-9` (202px) pero no es `position:relative` — sin
     eso, el `position:absolute` de `.gyo-nav__menu` toma como referencia a `.gyo-nav` (que
     también es absolute), cuya caja coincide en alto con la barra solo porque no tiene más
     contenido — más robusto anclarlo explícito a la barra misma. */
  .gyo-nav__bar {
    position: relative;
  }

  .gyo-nav--abierto .gyo-nav__menu {
    display: flex;
  }

  .gyo-nav__links {
    flex-direction: column;
    align-items: flex-start;
    gap: var(--gyo-nav-link-gap-6); /* 36px, mobile — ver nota de la regla base más arriba: ahora
      esta regla sí gana por debajo de 1329.98px (declarada después de la base en el archivo) */
    width: 100%;
  }

  .gyo-nav__links a {
    padding-bottom: 4px; /* el guion indicador (::after) mide 3px y en fila vertical no necesita
      los 19px de aire que tenía para separarse de la línea de base del texto en fila horizontal */
  }
}

/* Fase 3, Parte B (2026-08-18): estados hover. Sin dato del PDF (no hay estados dibujados, ver
   CLAUDE.md §6/puntos-abiertos.md Bloque E) — criterio propio, no vinculante al píxel. Familia
   "link de texto simple sin fondo propio" (nav, y más abajo dígitos de paginación): el hover pasa
   el texto al único acento del sitio (`--color-cafe-claro`) — es el mismo tratamiento en desktop y
   en el dropdown mobile, mismos selectores, sin necesidad de una regla aparte. Sigue funcionando
   igual para el link activo (queda con el guion + el texto también pasa a acento al pasar el
   mouse). */
.gyo-nav__links a:hover {
  color: var(--color-cafe-claro);
}

/* Indicador de página activa: guion de 17×3px. Color corregido 2026-08-14: el catálogo de
   componentes (Fase 0) lo daba por café-claro; la medición vectorial directa (rect propio, sin
   ambigüedad de glyph) y el muestreo de píxel del render confirman #ECE3D8 (beige) — ver
   _dev/registro-decisiones.md. */
.gyo-nav__links li.activa a::after {
  content: '';
  position: absolute;
  left: 50%;
  bottom: 0;
  transform: translateX(-50%);
  width: var(--gyo-nav-indicador-width-1);
  height: var(--gyo-nav-indicador-height-1);
  background-color: var(--color-beige);
}

.gyo-boton-outline--nav {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  height: var(--gyo-boton-height-5);
  padding-inline: var(--gyo-space-4);
  border: 1px solid var(--color-beige); /* medido: 1px exacto, ver registro-decisiones.md */
  background: transparent; /* sin relleno — re-medido P12/P13, no es fill(#ECE3D8) */
  color: var(--color-beige);
  font-size: var(--gyo-font-size-nav);
  text-transform: uppercase;
  transition: background-color 0.2s ease, color 0.2s ease;
  flex-shrink: 0; /* ver nota del bug real en .gyo-nav__logo — mismo criterio para los 3 grupos */
}

/* Familia "outline que se rellena": el botón CONTACTO (borde+texto beige, sin relleno) invierte a
   sólido en hover — mismo criterio que la familia de botón-flecha (boton-flecha.css), aplicado acá
   porque este botón no tiene un cuadrado sólido propio al lado del cual copiarle el color; se
   rellena con el mismo beige de su borde. */
.gyo-boton-outline--nav:hover {
  background-color: var(--color-beige);
  color: var(--color-negro-texto);
}

/* Variante "página actual": en `contacto.html` el botón CONTACTO se dibuja distinto al de las
   otras 6 páginas — relleno sólido gris claro (#D9D9D9, confirmado por muestreo de píxel directo,
   no por el glyph-fill que leía beige) + texto negro, sin borde. No es un estado de hover/foco
   documentado en puntos-abiertos.md — es el único caso en las 7 páginas donde el botón CONTACTO
   cambia de apariencia, y coincide exactamente con ser la página de destino del propio botón.
   Medido 2026-08-17, ver registro-decisiones.md. */
.gyo-boton-outline--nav--pagina-actual {
  border: none;
  background-color: #D9D9D9;
  color: var(--color-negro-texto);
  transition: filter 0.2s ease;
}

/* Familia "ya sólido por defecto": no hay a qué invertir (ya está relleno), así que el hover
   oscurece un poco el relleno existente en vez de cambiar de color — mismo criterio que
   `.gyo-paginacion__circulo--next` (paginacion-circular.css), el otro elemento del sitio que ya
   nace sólido. `filter:brightness()` en vez de un nuevo tono hex: no hay una variante "gris más
   oscuro" definida en la paleta (CLAUDE.md §3) ni motivo para inventar una solo para este hover.
   Reafirma su propio fondo/texto (en vez de heredar el hover de `.gyo-boton-outline--nav` de
   arriba, que por tener la misma especificidad y venir antes en el archivo lo pisaría a beige). */
.gyo-boton-outline--nav--pagina-actual:hover {
  background-color: #D9D9D9;
  color: var(--color-negro-texto);
  filter: brightness(0.92);
}