/* =============================================================================
   css/auth_modal.css — Ajustes de los modales de autenticación.
   =============================================================================

   ⚠️ LEER ESTO ANTES DE AGREGAR UNA SOLA REGLA ⚠️

   EL DISEÑO DE LOS MODALES YA EXISTE Y NO ESTÁ ACÁ.
   ---------------------------------------------------------------------------
   `includes/login.php` (~línea 3058) tiene un bloque titulado
   **"UNIFIED AUTH MODALS (2026-05-14)"**: un sistema de diseño completo, con
   tokens y casi todo en `!important`, que unifica `#loginModal` (login +
   registro + 2FA) con `#recoveryProcessModal` (recovery de 3 pasos).

   Ese sistema YA aplica el mismo lenguaje visual que el modal de pago:

       #loginModal .input-field              { border: 1px solid var(--auth-border) !important;
                                               border-radius: var(--auth-radius-sm) !important; }
       #loginModal .input-field:focus-within { border-color: var(--auth-primary) !important; }
       #loginModal .input-field input        { border: 0 !important; text-align: left !important; }
       .login-btn                            { background: var(--auth-primary) !important; }

   Sus tokens (`:root`, ~línea 3060) — 🎨 la paleta pasó al AMARILLO el 2026-08-26:

       --auth-primary #fcc201   --auth-primary-hover #1d1d1b   --auth-text #1f1f1f
       --auth-on-primary #1d1d1b                --auth-accent #8a6d00
       --auth-muted #6b7280     --auth-border #e5e7eb          --auth-bg #ffffff
       --auth-surface #f9fafb   --auth-error-bg #fef2f2        --auth-error-text #b91c1c

   ⚠️ EL AMARILLO NO ES UN REEMPLAZO 1:1 DEL ROJO. `--auth-primary` va SOLO como
   fondo y siempre con `--auth-on-primary` encima (blanco sobre amarillo da
   1,6:1, ilegible). Para texto o bordes SOBRE BLANCO va `--auth-accent`, que es
   el mismo amarillo oscurecido. La explicación larga está en el `:root` de
   `includes/login.php`. Los tokens de error siguen rojos a propósito.

   ↔️ Y el hover de los botones SE INVIERTE: fondo oscuro, texto amarillo. Por eso
   `--auth-primary-hover` es un oscuro y no un amarillo, y por eso las reglas de
   `:hover` declaran `color:` además de `background:`.
       --auth-radius 12px       --auth-radius-sm 8px           --auth-shadow …
       --auth-transition 220ms cubic-bezier(.2,.8,.2,1)

   QUÉ PASÓ EL 2026-08-13 (y por qué este archivo quedó tan corto)
   ---------------------------------------------------------------------------
   La primera versión de este archivo reimplementaba TODO ese diseño desde
   cero, sin saber que ya existía. Como el sistema unificado usa `!important` y
   esta capa no, el navegador terminó mezclando las dos: unas propiedades de
   una, otras de la otra. El modal se vio roto. Encima pisaba
   `.signin-signup { flex-direction: column }`, que es el contenedor absoluto
   que centra los tres formularios superpuestos, y los apilaba en vertical.

   La conclusión no fue "escribir mejores overrides" sino **borrarlos**: el
   diseño que el usuario quería ya estaba hecho en mayo. Lo único que faltaba
   era que se pudiera VER (§1).

   CÓMO SE TOCA EL DISEÑO DE LOS MODALES, ENTONCES
   ---------------------------------------------------------------------------
   1. ¿Cambiar un color, un radio, una sombra? → redefinir el TOKEN acá abajo.
      Es el punto de extensión que ese sistema ofrece y no pelea con nada.
   2. ¿Cambiar una regla concreta? → editarla EN `includes/login.php`, dentro
      del bloque unificado, donde vive el resto.
   3. ¿Cambiar maquetación? → NUNCA desde acá. `.modal_container`,
      `.signin-signup`, `.login-form`, `.panel` y `.panels-container` sostienen
      la animación entre login/registro y el estado 2FA, que además tiene su
      propia capa de reglas `!important` (líneas ~2298-3493 de login.php).
   ============================================================================= */


/* -----------------------------------------------------------------------------
   1. 🔴 Anular el `filter: grayscale(100%)` heredado
   --------------------------------------------------------------------------
   `includes/login.php` (~línea 775, bloque "ESTILOS MODAL LOGIN BLANCO & NEGRO")
   pinta el modal entero en escala de grises:

       .modal_container, .modal_container .panel { filter: grayscale(100%); }

   Esa regla es de 2024 y quedó ANTES del rediseño unificado de mayo de 2026.
   El resultado es que todo el trabajo de paleta de ese rediseño se ve en gris:
   el botón "INGRESAR" no sale en `--auth-primary`, sale gris.

   Y lo que más importa: el filtro también apaga el ROJO DEL ERROR
   (`--auth-error-text: #b91c1c`). Un campo mal completado queda gris sobre
   gris — se pierde la única señal de color que el formulario tiene para decir
   que algo falló. Eso no es una preferencia estética, es información.

   >>> ¿Se prefiere el modal en blanco y negro? Se borran estas 4 líneas y
       vuelve como estaba. Es el único efecto de este bloque. <<<
   -------------------------------------------------------------------------- */

#loginModal .modal_container,
#loginModal .modal_container .panel {
    filter: none;
}


/* -----------------------------------------------------------------------------
   2. Tokens — alineación fina con el modal de pago
   --------------------------------------------------------------------------
   El sistema unificado y el modal de pago (`.chk-*` en css/style.css) ya
   coinciden en lo importante: radio de 8px en los campos, borde de 1px gris
   claro, foco con el color primario, error en rojo. Las dos únicas diferencias
   medibles eran el tono exacto del borde y el gris del texto secundario.
   Se igualan a los valores del checkout para que, si alguien abre el login y
   después el pago, no vea dos grises distintos.

   Van sin `!important`: se declaran DESPUÉS del `:root` de login.php, y a
   igual especificidad gana la última. No hace falta forzar nada.
   -------------------------------------------------------------------------- */

:root {
    --auth-border: #ddd;        /* era #e5e7eb — `.chk-input` usa #ddd */
    --auth-muted:  #777;        /* era #6b7280 — el gris de `.chk-*` y del sitio */
}


/* -----------------------------------------------------------------------------
   3. Mobile — 16px al enfocar
   --------------------------------------------------------------------------
   Lo único que el sistema unificado NO cubre, y que el modal de pago sí
   resolvió (css/style.css, `@media (max-width: 479px) .chk-input`):
   iOS hace ZOOM automático al enfocar un input de menos de 16px, y después no
   vuelve solo. En un modal chico eso deja al usuario arrastrando la pantalla
   de costado para encontrar el botón.

   `!important` porque las reglas de tamaño del bloque unificado lo usan.
   -------------------------------------------------------------------------- */

@media (max-width: 479px) {
    #loginModal .input-field input,
    #recoveryProcessModal .rv-modal-content input {
        font-size: 16px !important;
    }
}