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.
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.
- Explicar por qué el corte codicioso produce líneas desequilibradas.
- Citar el tope de líneas de
balanceen cada motor y su consecuencia. - Distinguir qué optimiza
prettyfrente abalance. - 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.
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.
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.