/* ==========================================================================
   barra.css · LA CABECERA SE RETIRA AL BAJAR Y VUELVE AL SUBIR
   --------------------------------------------------------------------------
   Petición del cliente: "que la barra de navegación se oculte al hacer scroll
   para que no tape la vista de los otros elementos".

   POR QUÉ ESTA HOJA NO HACE NADA POR SÍ SOLA
   Todo cuelga de `html.barra-viva`, una clase que SÓLO escribe barra.js. Si el
   JavaScript no llega, falla o está desactivado, esa clase nunca aparece y la
   cabecera se queda exactamente como hoy: sticky, opaca a nada, visible. No se
   toca ni una propiedad del estado de reposo, así que el peor caso de esta
   hoja es "no pasa nada", nunca "la barra desapareció y no vuelve".

   POR QUÉ SE MUEVE LA CABECERA Y NO LA BARRA NEGRA DE REDES
   .social-top NO es sticky: vive en el flujo normal, en los primeros píxeles
   del documento (29px en escritorio, 44px por debajo de 900), y se va sola en
   cuanto se baja. Medido en 1440: con scrollY = 40 su
   getBoundingClientRect().bottom ya vale -11, o sea fuera de pantalla por
   arriba; en 375 lo está a partir de scrollY = 48. Después de esos primeros
   píxeles no tapa nada, luego no hay nada que retirar.

   Y hay una razón para no tocarla: su `position:relative; z-index:70` de
   profundidad.css existe porque el hero sube con margin-top negativo
   (-nav-alto - 26px = -104px) para meterse bajo la cabecera transparente, y sin
   posición la barra negra se quedaba debajo del hero. Convertirla en fija o
   sticky para poder ocultarla sería crear el problema (un elemento que sí tapa)
   para después resolverlo, y de paso reabrir ese apilado ya arreglado.

   DÓNDE VA EN EL ORDEN DE HOJAS
   Justo antes de profundidad.css, que sigue siendo la última. Comprobado hoja
   en mano: profundidad.css no escribe ni una regla sobre `.cabecera` (sólo
   sobre `.cabecera-int`, que es el banner de las interiores, y sobre
   `.social-top`), así que no hay disputa posible entre las dos.
   ========================================================================== */


/* --- 1. EL CARRIL DEL MOVIMIENTO -----------------------------------------
   La transición vive en la hoja y no la inyecta el JavaScript: así el primer
   ocultamiento ya sale deslizado, sin el fotograma de golpe que se ve cuando
   la transición se añade en el mismo momento que el estado.

   0.26s con salida rápida y frenada larga: el tiempo justo para que se lea el
   gesto sin que la barra se sienta perezosa cuando alguien baja de un tirón.

   NO lleva `will-change:transform` a propósito. Esa propiedad asciende la
   cabecera a capa propia PARA SIEMPRE, y una capa sin fondo opaco puede
   cambiar el suavizado del texto de subpíxel a escala de grises: el menú se
   vería ligeramente más flojo EN REPOSO, que es como se ve el 100% del tiempo.
   Los tres motores ascienden solos la capa mientras dura una transición de
   transform, así que el movimiento sale igual de suave y el texto quieto se
   queda nítido. El único coste es un fotograma de promoción al arrancar, y ahí
   la barra ya está en marcha: no se ve. */
html.barra-viva .cabecera{
  transition:transform .26s cubic-bezier(.4,0,.2,1);
}

/* --- 2. EL ESTADO RETIRADO ------------------------------------------------
   translateY negativo, no `display:none` ni `visibility:hidden`: la caja de
   maquetación se queda donde está, así que ni el hero ni el margen negativo de
   -104px se enteran de nada. Sólo cambia dónde se PINTA.

   El -14px extra sobre el -100% no es adorno, es una medida. La píldora blanca
   del menú lleva `box-shadow:0 2px 14px`, o sea 16px de sombra por debajo de su
   caja, y la píldora acaba 14.5px antes que la cabecera por el padding de
   ésta. Medido en 1440, con la transición apagada para leer el estado ya
   asentado:

     -100% pelado      píldora en -14.5  →  su sombra llega a  +1.5  ← asoma
     -100% - 14px      píldora en -28.5  →  su sombra llega a  -12.5 ← limpio

   Ese +1.5 se lee como una raya gris fina pegada al canto superior de la
   pantalla. Con los 14px de más, lo más bajo que pinta la cabecera queda 12.5px
   por encima del borde. (La sombra del botón Dona es sólida y de 3px, así que
   nunca fue la que asomaba: acaba en -25.) */
html.barra-viva.barra-retirada .cabecera{
  transform:translateY(calc(-100% - 14px));
}

/* --- 3. RED DE SEGURIDAD: EL FOCO DEL TECLADO ----------------------------
   barra.js ya vigila el foco, pero esta regla lo garantiza sin depender de que
   el JavaScript acierte: si hay algo enfocado POR TECLADO dentro de la
   cabecera, la cabecera no se va. Sin esto, quien navega con Tab podría enfocar
   el logo, el menú o el botón Dona con la barra fuera de pantalla, que es la
   definición de trampa de teclado: el anillo de foco está, pero no se ve.

   `:has(:focus-visible)` y NO `:focus-within`, que sería lo obvio. Medido: un
   clic de ratón o un toque también dejan el foco en el botón, así que con
   `:focus-within` la barra se quedaba clavada después de pulsar la hamburguesa
   o el botón Dona, hasta tocar otra cosa. `:focus-visible` sólo marca el foco
   que llegó por teclado, que es el único caso que hay que proteger. Es además
   la misma condición que aplica barra.js, y las dos tienen que coincidir: si
   una escondiera y la otra mostrara, la barra se quedaría a medias.

   Regla propia, no agrupada, por lo mismo que la de abajo: `:has()` no existe
   en navegadores viejos y un selector inválido anularía todo el grupo. */
html.barra-viva.barra-retirada .cabecera:has(:focus-visible){
  transform:none;
}

/* --- 4. RED DE SEGURIDAD: EL MENÚ DE MÓVIL ABIERTO -----------------------
   El desplegable de móvil es `position:absolute; top:calc(100% - 4px)` DENTRO
   de la cabecera, así que se iría con ella y el menú abierto desaparecería de
   la pantalla en cuanto el dedo rozara el scroll. barra.js ya lo contempla;
   esto lo respalda desde CSS.

   Va en su PROPIA regla y no agrupada con la anterior a propósito: `:has()` no
   existe en navegadores viejos, y un selector inválido dentro de una lista
   separada por comas anula la regla ENTERA. Aislado, lo peor que pasa es que
   este respaldo concreto no se aplique y quede sólo el control del JavaScript.
   ========================================================================= */
html.barra-viva.barra-retirada .cabecera:has(.menu.abierto){
  transform:none;
}


/* --- 5. MOVIMIENTO REDUCIDO: LA BARRA SE QUEDA QUIETA --------------------
   DECISIÓN: con prefers-reduced-motion la cabecera NO se retira. Ni deslizada
   ni de golpe: se queda fija y visible, igual que hoy.

   POR QUÉ ésta y no "aparece y desaparece sin animación":
   1. Un bloque de 87px clavado en el borde superior que aparece y desaparece de
      golpe no es "menos movimiento", es un parpadeo duro, y se repite muchas
      veces durante una lectura normal. Para quien pide movimiento reducido eso
      es peor que un deslizamiento lento, no mejor.
   2. Ocultarla es una mejora de comodidad visual, no de acceso: con la barra
      quieta no se vuelve inalcanzable ni ilegible nada. El coste de renunciar
      es bajo; el de parpadear, no.
   3. Deja una sola conducta de reserva que mantener: la misma que sin
      JavaScript. Un camino menos que probar y que se pueda romper.

   barra.js tampoco se activa en este modo, así que esta regla es el segundo
   cinturón: cubre el caso de que alguien cambie la preferencia del sistema con
   la barra ya retirada. */
@media (prefers-reduced-motion:reduce){
  html.barra-viva .cabecera{
    transition:none;
  }
  html.barra-viva.barra-retirada .cabecera{
    transform:none;
  }
}