/* safe_area.css — que las acciones no queden bajo la barra del navegador. * * ATL-1c (2026-07-29). Reemplaza el intento de ATL-1b, que NO funcionaba * en un iPhone real aunque pasara los tests: chromium headless no tiene * la barra de herramientas de Safari, así que el bug era invisible en * Playwright. * * ═══ POR QUÉ FALLÓ EL ARREGLO ANTERIOR ═══════════════════════════════ * * Eran TRES problemas combinados, no uno: * * 1. FALTABA `viewport-fit=cover` en el . * Sin él, Safari iOS devuelve CERO en todos los `env(safe-area-inset-*)`. * El `calc(96px + env(safe-area-inset-bottom, 0px))` de ATL-1b se * resolvía como 96px pelados: la mitad del arreglo nunca se activó. * Corregido en base.html — es requisito previo de todo lo demás. * * 2. `min-height: 100vh` en el (main.css:28). * En Safari iOS, `100vh` NO es la altura visible: es la altura que * tendría la ventana SIN la barra de herramientas. El body se * dimensiona más alto que el hueco real y su final queda por debajo * de la barra, incluso con la página scrolleada del todo. Es el * motivo de que "scrollear hasta abajo" no bastara. * Se corrige con `100dvh` (dynamic viewport height), que sí sigue el * alto visible cuando la barra aparece y desaparece. * * 3. El selector no cubría la pantalla. * ATL-1b aplicaba a `.reg-form-page, .dashboard-content`, pero el * formulario de sesión NO está dentro de `.dashboard-content`. Solo * valía la primera mitad del selector. * * ═══ POR QUÉ ESTAS REGLAS ════════════════════════════════════════════ * * · `100dvh` en vez de `100vh`: la unidad dinámica se recalcula cuando * la barra de Safari se contrae al hacer scroll. Con `100vh` el layout * se queda con la medida "barra oculta" aunque la barra esté visible. * Fallback a `100vh` antes, para navegadores sin dvh (se sobrescribe). * * · `padding-bottom` con DOS sumandos: * env(safe-area-inset-bottom) → el indicador de gestos del iPhone, * que es lo único que el sistema declara. * un margen fijo → la barra de herramientas FLOTANTE de Safari, que * NO está en ningún inset ni descontada del viewport. Es la parte * que hay que compensar a ojo; 88px cubre la barra de Safari (~50) * más holgura para no dejar el botón pegado al borde. * * · Se aplica a `.reg-form-page`, que comparten las OCHO pantallas de * formulario (las 6 de registro + nueva rutina + agenda). Por eso esta * hoja es compartida y no vive en el CSS de una pantalla. * * ⚠️ NO VERIFICABLE EN ESTE ENTORNO. Playwright headless no reproduce la * barra de Safari; estas reglas se comprueban en un iPhone real. Si * alguien las toca, que no se fíe de que los tests sigan verdes. */ :root { /* Compensación de la barra flotante de Safari iOS. No sale de ningún env(): iOS no la declara y tampoco la descuenta del viewport. */ --barra-navegador-movil: 88px; } /* El body se dimensionaba con 100vh (main.css:28), que en iOS ignora la barra. dvh sigue el alto REALMENTE visible. */ @media (max-width: 640px) { body { min-height: 100vh; /* fallback: navegadores sin dvh */ min-height: 100dvh; /* gana donde existe */ } } /* Las ocho pantallas de formulario comparten `.reg-form-page`: registro de peso, medidas, grasa, foto, comida y sesión de gym, más nueva rutina y el formulario de agenda. Más `.dashboard-content`, contenedor de las pantallas del atleta (Mi gym, Mi plan, nutrición). OJO CON LA CASCADA: esta hoja se carga en el y las hojas de cada pantalla van DESPUÉS, vía {% block extra_css %}. Varias declaran `padding` como shorthand (p.ej. registro_entreno.css:16), que reinicia el `padding-bottom` y borraría esta regla. Por eso el espacio NO se pone aquí como padding del contenedor, sino con un pseudo-elemento que ningún shorthand puede pisar. */ @media (max-width: 640px) { .reg-form-page::after, .dashboard-content::after { content: ""; display: block; height: calc( var(--barra-navegador-movil) + env(safe-area-inset-bottom, 0px) ); /* No captura toques ni altera el layout de los hijos: solo empuja el final del documento hacia arriba. */ pointer-events: none; flex: none; } }