正文
其实，CSS 工作组设计
pretty
的初衷，是希望每个浏览器都尽其所能地改进文本换行方式。在 CSS Text Level 4 的规范中，它是这样定义的（其中 “user agent” 是指浏览器，重点部分已加粗）：
浏览器可以（但不限于）尝试避免段落末尾出现过短的行…… 同时也应该在其他方面改进排版。具体的改进方式由各个浏览器自行决定，可能包括：减少各行长度的变化幅度、避免排版河流、优先考虑不同类型的软换行点、断字点或对齐机会，避免连续多行都使用断字。
这里使用的 “may”（可以） 这个词非常重要，它明确表示每个浏览器可以自主决定
pretty
的具体实现方式，并没有强制要求所有浏览器做出相同的选择。实际上，一个浏览器团队可能在 2025 年对某些排版特性做出支持，未来又会改变其实现方式。
由于 Chrome 的实现方式让很多开发者产生误解，大家以为
pretty
的作用只是防止段落结尾出现短行。但这其实并不是它的本意。事实上，CSS 工作组已经为这种特定需求定义了另一个属性值，它在上周刚被正式命名为
text-wrap: avoid-short-last-lines
。
实际试试看
你现在就可以在 Safari Technology Preview 216 中试用
text-wrap: pretty
。可以查看这个演示，切换
pretty
的开启与关闭状态，观察它带来的效果。你还可以开启或关闭断字、对齐等功能，尝试各种组合方式。开启辅助线或 “幽灵显示” 功能，有助于你理解背后的排版变化。也可以试试
text-wrap: balance
，看看两者的区别。这个演示还提供了英文、阿拉伯文、德文、中文和日文内容，让你能观察
pretty
在不同文字系统下的表现。
试试在 Safari Technology Preview 216 中体验这个演示。
https://codepen.io/jensimmons/pen/xxvoqNM?editors=1100
以下是一个英文文本示例，未使用
text-wrap
，也就是网页多年来使用的默认换行算法。我打开了 “显示辅助线（show guides）” 选项，用来标记文本框的边缘。绿色的垂直线标记了文本框的 inline-end 边界 —— 浏览器的排版算法会尽量让每一行都延伸到这个绿色线的位置。当文本达到这个边界时，浏览器就会换行。
三段文本，绿色的垂直线标记了文本框的右侧边缘。
接下来是同样的文本，但这次应用了
text-wrap: pretty
。你会发现绿色的边界线移动了。现在，浏览器的换行目标不再是文本框的最大宽度，而是提前一些换行，大约在一个范围之间换行，一定在洋红色线之后，也一定在红色线之前。这样可以改善文本边缘的参差不齐现象（rag）。
同样的文本示例，边缘更加整齐。辅助线显示有三条垂直线，间距大约 50 像素 —— 最右侧是红色线，左边 45 像素是绿色线，再往左 45 像素是洋红色线。
你还可以开启 “显示幽灵（show ghosts）”，查看优化前的版本作为背景对比。
同样的文本，排版更整齐的版本用正常颜色显示，旧版本（排版较差）用淡青色作为背景叠在后面，形成一个 “幽灵” 效果，让你清楚看到哪些行发生了变化，以及如何变化的。
此外，你还可以开启或关闭断字（hyphenation）和对齐（justification）功能，试试不同组合的效果。改变浏览器窗口的宽度，观察文字在不同宽度下的排版表现。
你可能会注意到，Safari Technology Preview 是对整段文本的每一行都应用
pretty
，而不是像其他浏览器那样只优化最后几行。因此，它对文本的整体影响更明显，整块文字呈现出一种更为 “整齐的矩形块” 效果。
你真的得自己试着给正文文本加上
text-wrap: pretty
，才能感受到它带来的巨大差异。它的效果虽然不夸张，但却很惊艳。如果你再配合使用段落间距为
1lh
，排版看起来会非常棒。
那么，为什么不是每个浏览器都全力优化排版呢？原因就是性能问题。
性能表现
许多开发者会担心
text-wrap: pretty
对性能的影响。虽然更好的排版视觉体验非常重要，但也不能以牺牲网页加载速度为代价。各浏览器团队在设定优化范围时，必须考虑用户所使用的设备性能和芯片能力。
我们对
Safari
所做的优化感到非常满意 —— 即使网页开发者在页面上大量使用
text-wrap: pretty
