Alineación óptica: 7 ajustes que los números no ven
Las letras redondas rebasan a las planas entre un 1% y un 3%, y la interfaz hereda el mismo problema. Siete ajustes ópticos y lo que ya resuelve el CSS.
En este texto
Un triángulo de play dentro de un botón redondo de 40px, centrado con place-items: center. Los números cuadran todos. En pantalla el triángulo se va hacia la izquierda. La alineación óptica es el ajuste que cierra la distancia entre lo que mide el layout y lo que lee el ojo, y en la mayoría de las interfaces de producto no llega nunca.
Los diseñadores de tipos llevan siglos aplicándola. Una O redonda se corta más alta que una H plana para que las dos se lean del mismo tamaño: ese rebase ronda el 1-3% de la altura de mayúsculas, y los manuales de producción de Peter Karow hablan de un 3% para la O y un 5% para la A. Las interfaces heredan el mismo problema en cuanto un círculo, un triángulo o una línea de texto entran en una caja que solo conoce sus propios bordes.
Por qué una interfaz centrada con números se ve torcida
El ojo centra la masa y el motor de layout centra los bordes. En un rectángulo las dos cosas coinciden, así que los cuadrados se centran solos y el resto se desplaza. El triángulo lleva el peso en el lado plano, y el centro geométrico deja demasiado del lado pesado. Un círculo inscrito en un cuadrado cubre alrededor del 79% (pi entre 4), así que con la misma caja un avatar redondo se lee más pequeño que una miniatura cuadrada. Una línea de texto vive dentro de una line box que incluye el espacio de ascendentes y descendentes que las letras quizá no usan, y el centrado vertical acaba hecho sobre métricas invisibles en vez de sobre las letras.
Esto no es cuestión de gusto. Es una diferencia medible entre dos cosas que la máquina trata como iguales, y es la razón por la que quien lleva años diseñando mueve las formas fuera de su centro real.
Los siete puntos donde se rompe en una interfaz de producto
1. El icono dentro de un botón redondo
El triángulo de play es el caso de manual: masa plana a la izquierda, punta a la derecha, y el centro geométrico lo hace leer corrido hacia la izquierda. Nosotros lo movemos hacia la punta un 3-6% del ancho del icono y lo miramos al tamaño real, no ampliado. En un glifo de 24px eso es un píxel: transform: translateX(1px). Vale para cualquier glifo de silueta asimétrica: la flecha de enviar, el marcador, el bocadillo con rabito.
El desplazamiento pertenece al componente. Una instancia que mueve su propio icono es un aviso de bug contra el botón, no un arreglo.
2. La etiqueta dentro de un botón o un chip
El padding vertical se aplica a la line box, no a las letras. Una etiqueta de 14px en un botón de 40px con 13px de padding arriba y abajo acaba baja, porque el espacio de las descendentes bajo la línea base queda vacío en una palabra como Guardar y lleno en una como Mejorar plan. El CSS ya lo resuelve de frente: text-box-trim con text-box-edge recorta el interlineado por encima de la altura de mayúsculas y por debajo de la línea base, y así el padding mide letras. El soporte llegó en Chrome y Edge 133 y en Safari 18.2, y Firefox a mediados de 2026 sigue sin tenerlo, o sea que queda fuera de Baseline. Va dentro de @supports (text-box: trim-both cap alphabetic), con el padding asimétrico de reserva, normalmente 1-2px menos abajo.
3. El tamaño óptico en las fuentes variables
Una tipografía dibujada para 12px y la misma dibujada para 48px son dos dibujos distintos: uniones más finas, espaciado más cerrado, aperturas menores a medida que crece el cuerpo. Las fuentes variables lo llevan en el eje opsz, y font-optical-sizing: auto es el valor por defecto del navegador: funciona solo, si el archivo trae el eje. Dos cosas lo rompen: font-variation-settings escrito a mano, que pisa el valor automático, y los archivos estáticos que salen de un pipeline de build que perdió el eje por el camino. Comprueba que el eje esté en el archivo que sirves de verdad, no en el que vive en la herramienta de diseño.
4. El tracking que cambia con el cuerpo y con las mayúsculas
Un solo valor de letter-spacing para toda la escala falla por los dos extremos. Nuestros valores de partida: 0,04-0,06em de más en etiquetas en mayúsculas a 12px, cero en todo el cuerpo de texto, y 0,01-0,02em de menos en los cuerpos display por encima de 40px. Las mayúsculas piden aire porque tienen los flancos planos y no hay ritmo de ascendentes que las separe; los cuerpos grandes piden lo contrario, porque el mismo espaciado relativo crece con el texto. El valor se guarda en el escalón de la escala, junto al cuerpo y al interlineado, como cualquier otro dato de una escala tipográfica.
5. Formas redondas al lado de formas cuadradas
Un avatar redondo de 40px junto a una miniatura cuadrada de 40px se lee más pequeño, justo por ese 79% de área. Nosotros agrandamos los elementos redondos un 4-8% respecto a los cuadrados de la misma fila, y luego miramos la fila al 100%. Los sistemas de iconos resuelven lo mismo con rejillas de keyline: los glifos redondos y cuadrados caben dentro de la rejilla, los altos y anchos pueden invadir el padding, y así todos los iconos se leen del mismo tamaño.
6. El padding alrededor de un glifo final
Los iconos llegan con espacio en blanco dentro del propio viewBox. Un botón con 16px de padding a cada lado y un chevron al final tiene 16px más lo que el chevron trae dentro, y el lado derecho se ve suelto. Se mide la tinta, no el SVG: se recorta el viewBox en el set de iconos, o se quitan 2-4px al padding final en el componente que junta texto e icono.
7. La puntuación al principio de la línea
Las comillas de apertura en lo alto de una cita rompen el filo izquierdo, porque el signo es pequeño, alto y casi todo espacio en blanco. La imprenta lo resuelve colgando el signo fuera de la columna. El CSS tiene hanging-punctuation, que solo funciona en Safari, y el valor last no está implementado en ningún navegador en 2026. Para una cita que tiene que aguantar en todas partes: el signo en un ::before con margen negativo, o un text-indent negativo en la primera línea.
Por qué sigue saliendo así
Tres causas, en el orden en que las vemos.
- Las herramientas centran por caja. La alineación de Figma y
place-itemstrabajan sobre los bordes. Nada del camino por defecto sabe qué es el peso visual, así que la versión sin corregir es la que cuesta cero. - El ajuste se queda en un override de instancia. Alguien mueve el triángulo dentro de una instancia, el valor no llega a ser un token, y la siguiente pantalla arranca del componente sin corregir. Es el component drift entrando por la puerta más pequeña que hay.
- La revisión compara el build con el spec. Si el spec salió de la geometría, el build coincide con el spec y en pantalla están torcidos los dos. Nadie en la cadena mira el píxel renderizado.
Lo que cuesta
No rompe ningún flujo y no tumba ninguna auditoría. El coste es ese comentario de revisión que nadie sabe localizar: la pantalla parece sin terminar, y tres personas se pasan una tarde recolocando el layout cuando el problema es un píxel dentro de un botón. Y es un coste que se multiplica, porque el componente sin corregir se copia en cada pantalla nueva: arreglarlo en el componente sale barato, arreglarlo cuando el mismo fallo está en cuarenta pantallas sale caro.
Una condición sobre los propios ajustes: si el ajuste aprieta el padding, el área de pulsación se mantiene. Las WCAG 2.2 fijan un objetivo mínimo de 24 por 24 píxeles CSS en nivel AA, y un recorte óptico que deje un botón de icono por debajo cambia un problema de acabado por uno de cumplimiento.
Cómo arreglar lo que ya está publicado
- Captura las tres pantallas más densas al 100% de zoom. Los errores ópticos desaparecen al ampliar, y por eso sobreviven a una revisión hecha en un monitor de 27 pulgadas.
- Voltea la captura en horizontal. El espejo desarma el reconocimiento de patrones que estaba compensando el error, y lo torcido salta a la vista.
- Desenfócala 8px. El detalle se va, la distribución de masa se queda. Lo que se ve escorado en el desenfoque también lo está en el original.
- Corrige en el componente, nunca en la instancia. Un cambio en el botón de icono vale más que cuarenta overrides, y es la única versión que sobrevive al siguiente rediseño.
- Ponle nombre a cada ajuste. Una constante
--optical-shift-triangle: 1pxse revisa, se busca y se quita. UntranslateX(1px)suelto en la hoja de estilos es folclore. - Vuelve a medir las áreas de pulsación al terminar. Los recortes ópticos encogen cajas.
Cómo dejarlo fuera
Cuatro reglas aguantan en la práctica. Los ajustes ópticos pertenecen a los componentes, así que un movimiento hecho en la instancia se trata como defecto del componente. El tracking vive en la escala tipográfica, un valor por escalón y no por uso. El recorte moderno del texto va dentro de @supports con el padding de reserva intacto, para que quien use Firefox vea el comportamiento de siempre y no uno roto. Y la revisión de diseño gana una pregunta: ¿hay algo que chirríe cuando la pantalla está en espejo?
Son ajustes pequeños, viejos y casi todos codificables. Lo que no se codifica es la comprobación final, la misma que en los tiempos del plomo: pon la cosa en pantalla al tamaño al que la va a ver la gente, y mírala.
Preguntas frecuentes
¿La alineación óptica es solo ir a ojo?+
No. Buena parte son números que el diseño de tipos fijó hace mucho: un rebase del 1 al 3% de la altura de mayúsculas, un círculo que cubre el 79% del cuadrado que lo contiene, un tracking que cambia con el cuerpo y con las mayúsculas. Esos valores se escriben en componentes y tokens y se revisan como cualquier otro código. Lo que sigue siendo subjetivo es el último paso, mirar la pantalla renderizada al tamaño al que la ve una persona, porque entre métricas de fuentes y sets de iconos hay demasiada variación para una sola constante.
¿Cuánto hay que mover un icono dentro de un botón redondo?+
Se empieza por un 3-6% del ancho del icono, hacia la punta visual de la forma, y solo en glifos con masa asimétrica: triángulos de play, flechas de enviar, marcadores, bocadillos con rabito. En un icono de 24px eso es un píxel. Los glifos simétricos (círculo, cuadrado, más, engranaje) no se mueven, y moverlos los empeora. La comprobación se hace al tamaño real en una pantalla normal, no al 400% dentro de la herramienta de diseño.
¿En 2026 el CSS resuelve solo la alineación óptica?+
En parte. El recorte de texto (text-box-trim con text-box-edge) quita el interlineado que deja bajas las etiquetas, y font-optical-sizing aplica el eje opsz de una fuente variable al tamaño renderizado sin tocar nada. Ninguna de las dos cubre todo: el recorte de texto a mediados de 2026 falta en Firefox, y hanging-punctuation solo existe en Safari. Para los iconos no hay nada, porque el navegador no sabe qué es la masa visual dentro de un SVG, así que los ajustes de forma siguen siendo una decisión de componente.
Servicios relacionados
Studio
Empieza un proyecto.
Escribimos sobre lo que construimos. Cuéntanos qué quieres construir tú.