Ingeniería
Una sola línea de CSS para que el diseño escale en cualquier pantalla
Cómo la landing de Ikoodi se ve proporcionalmente igual en 1280, 1728, 1920 y 4K con un único clamp() en la raíz — y por qué eso obliga a desterrar el píxel.
Jesús Barros · · 3 min de lectura
El mockup llega en un frame de 1728 píxeles. La pantalla del cliente tiene 2560. La del comercial, 1280. Y el diseño tiene que verse igual en las tres: no reorganizado, no con más columnas — igual, a otra escala.
La solución habitual es picar breakpoints y repetir cada medida tres veces. Nosotros lo resolvimos con una línea.
El truco: la raíz manda
Toda la escala de Tailwind v4 está en rem, y un rem es el font-size del
elemento raíz. Si ese valor crece con el ancho de la ventana, crecen con él
el texto, los paddings, los márgenes, los gaps, los radios, los anchos y los
iconos. Todos a la vez y en la misma proporción.
html {
font-size: clamp(0.741rem, 0.926vw, 1.481rem);
}
A 1728 píxeles la raíz vale exactamente 16px, que es la referencia del
mockup. Por debajo y por encima, el clamp() interpola:
| Ancho de pantalla | Escala |
|---|---|
| 1280 | 0,741× |
| 1728 | 1,000× |
| 1920 | 1,111× |
| 2560 | 1,481× (techo) |
El techo importa: sin él, en un monitor de 4K el texto alcanzaría tamaños absurdos. A partir de 2560 la interfaz deja de crecer.
La consecuencia: traducir Figma es dividir entre cuatro
Como la raíz vale 16px en la referencia y la escala de spacing de Tailwind avanza de 4 en 4 píxeles, una unidad de spacing equivale a 4px del mockup. Traducir una medida deja de ser una interpretación y pasa a ser una división:
- 24px →
p-6 - 44px →
size-11 - 18px →
text-lg
No hay que mirar la tabla de Tailwind ni discutir si «eso son seis o siete». Se divide entre cuatro y se acabó.
El precio: un píxel suelto rompe la proporción
Esto es lo que nadie cuenta. Si el sistema escala en bloque, cualquier medida en píxeles se queda quieta mientras todo lo demás crece. A 1728 no se nota. A 2560 la sombra es la mitad de grande de lo que debería, el borde se ve fino y el desplazamiento de una animación se queda corto.
Por eso, en nuestro sistema, todo lo que sea una medida va en rem:
incluidas las sombras, el blur, el outline y los desplazamientos de las
animaciones.
El caso más traicionero son los bordes. La utilidad border de Tailwind es
1px fijo, así que tuvimos que sustituirla por una propia:
.border-hair {
border-width: var(--border-hairline);
}
Lo que NO se mueve: los breakpoints
Un detalle contraintuitivo: los rem dentro de una media query siempre
valen 16px, sin importar el font-size de la raíz. Así lo especifica CSS.
Es una suerte, no un problema: significa que los breakpoints se quedan donde están y el escalado no los arrastra. Intentar compensarlos es el error clásico — y produce saltos imposibles de depurar.
Dónde se acaba
Por debajo de 1280 la raíz vuelve a 16px y manda el layout responsive. Y ahí está el límite real de la técnica:
Un diseño de escritorio no se escala hacia el móvil. Se rediseña.
Escalar hacia abajo produce interfaces con el texto diminuto y áreas táctiles inalcanzables. El escalado fluido resuelve el rango de escritorio, que es donde el problema era repetitivo y mecánico. El móvil sigue siendo una decisión de diseño.