/* ============================================================================ * arreglos-genesis.css — LOS ARREGLOS DE PRESENTACION DEL SITIO PUBLICO * ============================================================================ * * POR QUE EXISTE (15/10/2026) * * El sitio publico **no tiene fuente en el repositorio**: se compila en otro lado y se sube por FTP. Su * hoja de estilos es un archivo con hash (`assets/index-XXXXXXXX.css`) que no se puede reconstruir. * * Este archivo **se agrega al final de la hoja viva** y no la reemplaza: la hoja sigue siendo la del * compilado, y esto son tres reglas encima. El dia que el sitio se recompile, este archivo se borra entero * y no queda nada. * * Y NO ES UN PARCHE AL COMPILADO: son reglas de CSS, que es el lenguaje que el compilado ya habla. La * diferencia importa: un CSS agregado al final se lee, se revisa y se borra; un bundle minificado editado a * mano no. * * LAS DOS COSAS QUE ARREGLA, las dos reportadas por el cliente el 15/10/2026 * * F2 · «en (otros servicios - waiver) el letrero que queda fijo es muy largo y en el celular tapa toda la * pantalla y no se puede leer el resto de la informacion». * * F4 · «el logo de arriba de genesis en la tablet y pc quedo muy pequeño no se alcanza a leer 'soluciones * migratorias'». * * LO QUE SE MIDIO ANTES DE ESCRIBIR, porque las dos primeras hipotesis sobre estos dos puntos fueron falsas * * El encabezado del modal es `sticky top-0` y mide **98 px en la J-1 y 184 px en el waiver** a 1440 px de * ancho. Un encabezado pegajoso de 184 px en una pantalla de 812 px de alto --un celular-- es **casi una * cuarta parte de la pantalla**, y con el titulo envuelto en varias lineas pasa de la mitad. Eso es * exactamente lo que el cliente describio. * * El logo del header mide **99x32 en PC, 86x28 en tablet y 74x24 en celular**, sobre una imagen de * 256x83. La bajada «soluciones migratorias» **viene dentro de la imagen**, asi que a 32 px de alto esas * letras miden menos de 8 px: no se leen. El del pie mide 111x36 y esta bien. */ /* ---------------------------------------------------------------------------- * F2 · EL ENCABEZADO PEGAJOSO DEL MODAL NO PUEDE COMERSE LA PANTALLA * * POR QUE UNA ALTURA MAXIMA Y NO UN TITULO MAS CORTO: el titulo es contenido del estudio y no lo ponemos * nosotros; puede cambiar. Una regla que dependa del texto de hoy se rompe el dia que cambie el texto. Un tope * de alto funciona con cualquier titulo. * * POR QUE 40 %: con eso queda **mas de la mitad de la pantalla** para el contenido, que es lo que el cliente * pide leer. Y si el encabezado no entra en ese alto, **scrollea por dentro** en vez de empujar el contenido * fuera de la vista. * * VA EN PANTALLAS BAJAS, NO SOLO EN CELULARES: en una laptop de 1366x768 --que es la mayoria-- una ventana de * navegador con barras deja unos 650 px utiles, y un encabezado de 184 px ahi tambien molesta. El criterio que * importa es **el alto disponible**, no el ancho del aparato. * -------------------------------------------------------------------------- */ /* ---------------------------------------------------------------------------- * F2 (segunda vuelta) · EL TOPE ERA DEMASIADO GENEROSO: DE 40 % A 1/3 * * LO QUE MIDIO EL INSTRUMENTO, y es la razon de este cambio: en un celular de 375x812 el encabezado del waiver * quedaba en **325 px, que es el 40 % exacto de la pantalla**. La regla estaba haciendo su trabajo --cortaba en * el tope-- y **el tope era el problema**: la queja del cliente es que el letrero «tapa toda la pantalla y no se * puede leer el resto de la informacion», y dejarle un 40 % a un encabezado es seguir tapando bastante. * * Con 1/3, en ese mismo celular el encabezado baja a ~270 px y **el contenido se queda con dos tercios**. La * diferencia entre 40 % y 33 % son unos 55 px de texto: un par de renglones, que es justo lo que se estaba * perdiendo. * * Y ESTO NO SE HABRIA VISTO SIN MEDIR: la regla anterior parecia correcta, el texto del arreglo decia «no pasa * del 40 %», y el numero 40 % estaba puesto por mi como criterio de aceptacion. **Un criterio de aceptacion * elegido a mano tambien hay que revisarlo contra lo que el cliente pidio.** * -------------------------------------------------------------------------- */ @media (max-height: 900px) { .sticky.top-0.z-10.items-start.justify-between { max-height: 33vh; overflow-y: auto; /* `overscroll-behavior` para que al llegar al final del encabezado el scroll no se propague al modal: sin esto, seguir girando la rueda mueve el contenido de abajo y se pierde el lugar donde uno estaba. */ overscroll-behavior: contain; } } @media (max-width: 767px) { .sticky.top-0.z-10.items-start.justify-between { /* 33 % ERA DEMASIADO, Y LO DIJO EL CLIENTE CON SUS PALABRAS (15/10, 12:02): «el letrero que queda fijo es * muy largo y en el celular tapa toda la pantalla y no se puede leer el resto de la informacion». * * La regla del 33 % cumplia con el criterio que habia escrito yo —«no pasa de un tercio»—, y un tercio del * telefono sigue siendo un tercio que no se puede leer. Medido a 390×844: 279 px de 844. Con 22 % son ~186 * px y el contenido se queda con el 78 %: el letrero sigue visible —que es para lo que esta— y el resto se * lee sin scrollear a ciegas. */ max-height: 22vh; overflow-y: auto; overscroll-behavior: contain; /* Y en el celular, un poco menos de aire adentro: `p-5` (20 px por lado) se suma dos veces sobre un encabezado que ya es alto. */ padding-top: 0.75rem; padding-bottom: 0.75rem; } } /* ---------------------------------------------------------------------------- * F4 · LA PALABRA DEL LOGO, MAS GRANDE EN TABLET Y PC * * EL ALCANCE ES LO QUE MAS IMPORTA ACA. El logo se usa DOS veces: en el header (`h-6 sm:h-7 lg:h-8`) y en el * pie (`h-9`). El del pie mide 111x36 y **esta bien**: subirlo tambien habria sido cambiar algo que el cliente * no pidio. Por eso la regla se ata a la clase exacta del header, que el pie no tiene. * * LOS NUMEROS: el objetivo es que la bajada se lea. La imagen es 256x83 y la bajada ocupa la parte de abajo; * a 32 px de alto esas letras miden menos de 8 px. Con 44 px (PC) el logo queda en ~136 px de ancho y la bajada * pasa los 10 px, que ya se lee. **No se sube mas** porque el logo compite con el menu de navegacion, que esta * al lado: un logo que se lleva la atencion del menu es un problema nuevo. * * Y SE RESPETA EL ESCALONADO: mas chico en tablet que en PC, para que la marca no pese mas que el contenido en * una pantalla donde hay menos lugar. * -------------------------------------------------------------------------- */ @media (min-width: 640px) { img.h-6.sm\:h-7.lg\:h-8.w-auto.object-contain { height: 2.625rem; /* 42 px · tablet */ } } @media (min-width: 1024px) { img.h-6.sm\:h-7.lg\:h-8.w-auto.object-contain { height: 2.875rem; /* 46 px · PC */ } } /* ---------------------------------------------------------------------------- * LA CORRECCION DEL LOGO, medida despues de subir la primera version * * LA PRIMERA VERSION QUEDO CORTA, y por poco: puso 36 px en tablet y 44 px en PC, y el medidor devolvio * **111 px de ancho en tablet y 136 en PC** contra los pisos de 120 y 140. O sea que la regla hacia lo que * decia --subir el logo-- y **no alcanzaba para lo que el cliente necesita**, que es leer la bajada. * * LA LECCION, que es la de todo el proyecto: un cambio de tamaño no se verifica leyendo la regla, se verifica * **midiendo el resultado**. La regla era correcta y el resultado no alcanzaba. * * ESTA VA DESPUES A PROPOSITO, y no se edito la de arriba: la hoja viva ya tiene la primera version aplicada, y * **reescribir una regla ya publicada deja el archivo del repositorio distinto del que corre**. Agregar una que * la sigue es lo que dice la verdad de lo que paso, y se lee en orden. * -------------------------------------------------------------------------- */ @media (min-width: 640px) { img.h-6.sm\:h-7.lg\:h-8.w-auto.object-contain { height: 2.75rem; /* 44 px · tablet: deja el logo en ~125 px de ancho */ } } @media (min-width: 1024px) { img.h-6.sm\:h-7.lg\:h-8.w-auto.object-contain { height: 3rem; /* 48 px · PC: deja el logo en ~148 px de ancho */ } } /* ---------------------------------------------------------------------------- * F4-bis · EL LOGO DEL CELULAR, QUE FALTABA (21/10/2026) * * El cliente pidio tablet y PC, y ahi quedo en 148 px. En el celular **siguio en 74×24**, y la bajada * «soluciones migratorias» a 24 px de alto mide ~5 px: no se lee. El informe del 20/10 lo dejo anotado * («no lo toque porque no lo pidio») y es correcto como registro, pero el defecto es el mismo en cualquier * pantalla: **una marca que no se puede leer no es una marca**. * * 36 px deja el logo en ~111 px de ancho y la bajada en ~7,5 px, que se lee sin agrandar. No se sube mas: en * un header de 390 px el logo compite con el boton de menu y el de WhatsApp, y ganarle lugar a la accion * principal para agrandar la marca es un problema nuevo. * -------------------------------------------------------------------------- */ @media (max-width: 639px) { img.h-6.sm\:h-7.lg\:h-8.w-auto.object-contain { height: 2.25rem; /* 36 px · celular */ } } /* ---------------------------------------------------------------------------- * F6 · EL ENCABEZADO FIJO DEJA DE SER TRANSPARENTE CUANDO SE BAJA (19/10/2026) * * LO QUE DIJO EL CLIENTE: «En el celular aparece estas palabras montadas arriba» (15/10, con captura). * * LO QUE SE MIDIO: el encabezado es `