wandres.dev
DETALLES TIPOGRÁFICOS · text-wrap, hyphens, features

text-wrap: balance y pretty

Cómo falla el corte de línea codicioso, el tope de líneas que cada motor impone a balance, qué hace pretty en textos largos y dónde aplicar cada uno.

⏱ 16 min

El algoritmo de corte de línea que usa la web desde 1994 es codicioso: mete en cada línea todo lo que cabe y pasa a la siguiente. Es rápido, es predecible y produce titulares con la última línea de dos letras. balance y pretty son dos algoritmos alternativos con costes y límites distintos, y esos límites —empezando por el número de líneas que cada motor está dispuesto a equilibrar— deciden dónde se pueden usar.

🎯 Al terminar esta lección sabrás
  • Explicar por qué el corte codicioso produce líneas desequilibradas.
  • Citar el tope de líneas de balance en cada motor y su consecuencia.
  • Distinguir qué optimiza pretty frente a balance.
  • Elegir el valor adecuado según el tipo de bloque.

Por qué el corte codicioso falla

El algoritmo llena cada línea al máximo sin mirar las siguientes. Para un párrafo de quince líneas eso está bien: el desequilibrio se reparte y solo la última línea puede quedar corta. Para un titular de tres líneas, no: toda la irregularidad se concentra en un bloque que el ojo abarca de una vez.

El caso peor es el titular de dos líneas donde la segunda tiene una palabra. El ojo lee eso como un error de maquetación, y lo es: hay una composición mejor —repartir las palabras entre las dos líneas— que el algoritmo no busca porque no mira hacia adelante.

text-wrap es la abreviatura de dos longhands: text-wrap-mode, que decide si se corta o no —lo que antes eran white-space: nowrap y compañía—, y text-wrap-style, que decide cómo se corta. Los valores de esta lección pertenecen al segundo.

balance y su tope de líneas

h1, h2, h3, blockquote, figcaption {
  text-wrap: balance;
}

El motor busca la anchura de línea que iguale al máximo la longitud de todas las líneas del bloque, normalmente con una búsqueda binaria sobre el ancho disponible. El resultado son titulares repartidos y sin líneas huérfanas.

Y aquí está el límite que hay que conocer, porque no está en ninguna advertencia visible: cada motor impone un tope de líneas por encima del cual desactiva el equilibrado en silencio.

motor tope
Chromium 6 líneas
Firefox 10 líneas
Safari sin tope declarado

El motivo es el coste: el equilibrado exige recomponer el bloque varias veces, y en un párrafo largo eso multiplica el trabajo de layout. Los topes son un cortafuegos de rendimiento.

La consecuencia práctica es traicionera. Un titular de cinco líneas se equilibra en Chromium; el mismo titular traducido al alemán, con palabras más largas, pasa a siete líneas y deja de equilibrarse sin que nadie se entere. No hay error, no hay aviso, y el fallo aparece solo en el idioma que tú no revisas.

De ahí la regla: aplica balance únicamente a bloques cuya longitud controlas, y trátalo como una mejora que puede no aplicarse en lugar de como una garantía de composición.

El soporte de balance está en los tres motores: Chrome 130, Firefox 124 y Safari 17.5 para el longhand text-wrap-style, y algo antes a través de la abreviatura.

pretty y el texto largo

p, li {
  text-wrap: pretty;
}

pretty optimiza otra cosa: en lugar de igualar las líneas, evita los resultados feos, empezando por la línea final huérfana —una sola palabra sola al final de un párrafo— y, en las implementaciones más recientes, considerando el párrafo entero para elegir cortes mejores.

Como no busca igualar, no necesita recomponer tantas veces y no tiene tope de líneas. Es el valor pensado para texto corrido.

El reparto de soporte sí es desigual: pretty está en Chromium desde la 130 en el longhand y en Safari desde la 26, y Firefox no lo ha implementado. La degradación es automática y limpia: un motor que no reconoce el valor descarta la declaración y compone como siempre. No hace falta ninguna detección, y es un caso de manual de mejora que no necesita @supports.

Hay un tercer valor, stable, que garantiza que las líneas ya compuestas no se recolocan al editar el contenido. Su caso de uso es el texto editable, donde los otros valores producen un reflujo desconcertante mientras se escribe.

Dónde aplicar cada uno

bloque valor motivo
titulares de una a cuatro líneas balance el reparto se ve, el tope no molesta
pies de figura y citas breves balance igual
mensajes de aviso y globos de texto balance bloques cortos donde la forma importa
párrafos de contenido pretty evita huérfanas sin tope de líneas
elementos de lista pretty ídem
texto editable stable evita que las líneas bailen al escribir
tablas y datos ninguno el corte codicioso es lo previsible

Dos avisos sobre balance que ahorran depuración.

No se lleva bien con los saltos manuales. Si el titular lleva un salto explícito, ya has decidido tú el reparto y el equilibrado trabaja sobre los trozos, con resultados sorprendentes. Elige una cosa o la otra.

Depende del ancho, así que cambia al redimensionar. Es lo esperable, pero significa que el reparto que has aprobado en la revisión de diseño es el de ese ancho concreto y no el de todos.

ℹ️
Ninguno de los dos parte palabras

balance y pretty eligen dónde cortar entre palabras. Si una palabra no cabe en el ancho disponible, ninguno de los dos la puede salvar: se desborda o se pasa entera a la línea siguiente dejando un hueco enorme. El que corta palabras es la partición silábica, y en columnas estrechas es esa, y no el equilibrado, la que arregla el problema de verdad.

Un tope de rendimiento invisible es una funcionalidad que se apaga sola

El tope de seis líneas de Chromium es una decisión de ingeniería impecable —equilibrar un texto largo es caro y el beneficio decrece— y a la vez es el tipo de límite más difícil de convivir con él, porque el modo de fallo es silencioso y depende del contenido. Todo funciona en desarrollo, donde los titulares son cortos porque los escribiste tú; falla en producción, con contenido real, en el idioma con las palabras más largas, y en la única página que nadie revisa. No hay forma de detectarlo desde CSS, no aparece en ninguna herramienta y no genera ningún aviso. La disciplina que protege de esta familia entera de problemas —y hay muchos más: el tope de anidamiento de algunos selectores, los límites de tamaño de las capas del compositor, el número de fuentes que un navegador descarga en paralelo— es probar con el contenido más largo y más hostil que el sistema pueda producir, no con el que tienes a mano. Y en el caso concreto de balance, aceptar de entrada que es un adorno que puede desaparecer: si tu composición necesita estar equilibrada para no verse rota, el problema no está en el text-wrap, está en que el titular es demasiado largo para el sitio que le has dado.